Canonical открывает в свободный доступ один из компонентов Launchpad

Мда. То откроем, то не откроем... Canonical с каждым днём всё больше напоминает мне Sun.

Фигли не 3?

>>Фигли не 3?

А фигли должны?

Тебе халяву дали - а ты еще и претензии предъявляешь.

Спасибо

>Мда. То откроем, то не откроем...

По-моему, они всегда говорили, что откроют. Просто код кривоват пока --- причёсывают.

Это не нужно. Есть SQLAlchemy.

А кто может сказать, как оно в сравнении с sqlobject?

Это чтоб SQL не учить?

чет не нашел, какие бд знает... или ему без разницы,лишь бы бинд был?

> А кто может сказать, как оно в сравнении с sqlobject?

sqlobject - говно. вы еще это не поняли? все проекты, использующие sqlobject, перешли/переходят на sqlalchemy.

Это чтоб SQL не учить? Непонятна сама идея объектного подхода к работе с БД.

> Это чтоб SQL не учить? Непонятна сама идея объектного подхода к работе с БД.

Просто ты тупенький. Это, во-первых, позволяет абстрагироваться от особенностей БД - ваша программа может работать с любой поддерживаемой БД, об этом позаботится ОРМ. Во-вторых, это позволяет работать с БД на том языке, на котором ведется вся остальная разработка, что освобождает васм от постоянного "переключения контекстов" с SQL на Python, что в свою очередь способствует повышению продуктивности, и минимизирует вероятность появления ошибок.

>Это чтоб SQL не учить? Непонятна сама идея объектного подхода к работе с БД.

Нет, это что бы проще разрабатывать приложения, работающие с реляционными бд, на обьектно-ориентированном языке программирования.

Launchpad'ом зовут в летчика в Утиных Историях
http://en.wikipedia.org/wiki/Launchpad_McQuack

Пока в браузере язык не сменил - на сайте херь какая-то.

Подскажите плз, это примерно для тех же целей, что и DBI для перла?

> Подскажите плз, это примерно для тех же целей, что и DBI для перла?

Чушь. Для тех же целей в питоне db-api. Это совсем другое.

кто выпустил перловика из дома престарелых?!

могут закрывать взад свой недоделанный велосипед. у нас давно есть куда более полные и отлаженные решения. то, что они открыли, можно за пару вечеров нарисовать.

> Launchpad'ом зовут в летчика в Утиных Историях > http://en.wikipedia.org/wiki/Launchpad_McQuack

Вау, Зигзаг МакКряк? Как же, как же, смотрели...

> кто выпустил перловика из дома престарелых?!

Я думал последнего из них заспиртовали в 2003.

SQLite, PostgreSQL, MySQL.

>> Это чтоб SQL не учить? Непонятна сама идея объектного подхода к работе с БД.

> Просто ты тупенький. Это, во-первых, позволяет абстрагироваться от особенностей БД - ваша программа может работать с любой поддерживаемой БД, об этом позаботится ОРМ. Во-вторых, это позволяет работать с БД на том языке, на котором ведется вся остальная разработка, что освобождает васм от постоянного "переключения контекстов" с SQL на Python, что в свою очередь способствует повышению продуктивности, и минимизирует вероятность появления ошибок.

Зависит от области применения. У нас для транзакций подобная фигня не используется. Тормозит и отлаживать тяжело. Проблемы с использованием SQL не вижу.

Lol, не оправдывайся быдлокодер, всем понятно что ты даже обычных библиотек абстракции на бд не потянул

Библиотеки абстракции к БД - зло.

Каждая база уникальна (к сожалению), поэтому для ускорения работы используются свои фичи (хинты у оракла, хитрые запросы в фаербёрд для обхода кривизны его планировщика и т.д.)

А еще один ODBC на хрен не нужен. В нормальных проектах абстракции и так встроенные и для перехода на новую БД (что кстати редко происходит) просто переписывается слой работы с БД (или используется другая библиотека).

А так - в топку ...

Значит у вас именно херня. Что удобнее?
c=conn.cursor()
c.execute('select f,i,o from employers where birthday=now()')
for row in c.fetchall():
         e = employet(f=row[0],i=row[1],o=row[2])
         e.message('С днем рождения')
Или
for e in e.objects.get(birthday=now()):
            e.message('С днем рождения')

Пипец сколько умных... Причем тут ODBC? Причем тут фичи SQL??? Некоторые ORM мапперы даже позволяют передать им SQL... Мля народ ни в зуб нагой и лезет в бутылку. вопли из серии Нафиг самолет он большой - ходите пешком.

SQLAlchemy наше все!

Вообще ORM удобны когда не охота возится со sql, и не нужны фичи какой-то конкретной БД...

> for e in e.objects.get(birthday=now()):
e.message('С днем рождения')

Или select = Test1.select(EXISTS(Select(Test2.q.col2, where=(Outer(Test1).q.col1 == Test2.q.col2)))) - не знаю кого как, а у меня начинаются рвотные позывы от таких вот извращений. И еще от эффективности того SELECT-а, который оно нагенерит. И если такие конструкции все время использовать, то никакая оптимизация тебе не поможет.

> Это, во-первых, позволяет абстрагироваться от особенностей БД - ваша программа может работать с любой поддерживаемой БД, об этом позаботится ОРМ.

1) Это тогда, когда стоит бизнес-задача - обеспечить поддержку максимального числа БД. Эта задача, в некотором приближении, выполнима, но надо понимать, каким гемором это дается.
2) БД разные, их возможности разные, сложность SQL разная. Надо выбрать БД исходя из условий задачи и использовать возможности БД на полную катушку.
3) ОО подход здесь сбоку припеку. Не ложится БД на ООП-нутый подход.

API выглядит приятно. Правда, доки мало, и непонятно, как они разруливают всякие select ... for update, и как в многонитевом веб-приложении работать с несколькими Store. В SQLAlchemy приходится делать session_context.current.clear()...

Так никто и не требует использовать ORM для задач типа увеличить колонку в таблице на 1. ОРМ нужен когда объект надолго поднят из БД и с ним выполняется множество операцию Часто его свойства суть ссылки к другим таблицам. Вот там застрелиться хочется когда надо пол сотни полей в объект и из объекта.... А насчет оптимизации SQL - все эти жалобы похожи на крики - давайте перепишем все на ассемблере? Часто ORM выдает куда более эффективный код чем программист которого уже достало в 1001 раз за день мапить колонки из и в SQL

> Lol, не оправдывайся быдлокодер, всем понятно что ты даже обычных библиотек абстракции на бд не потянул

Ну протестровали мы парочку ORM. Там когда 15 таблиц мапятца, Perl код какой-то получается, а не вызов. Так что мы лучше по-старинке. SQL код читается легко. А умным кодерам желаю успехов в освоении. Ещё можно обращения к базе данных на XML писАть, советую умникам тоже обязательно внедрить в свои программы.

> select = Test1.select(EXISTS(Select(Test2.q.col2, where=(Outer(Test1).q.col1 == Test2.q.col2))))

Perl? LISP? У меня 1000 связанных таблиц в базе. Чур меня, чур...

python, под Лисп я такого не встречал, да и ООП-щиной там мало кто увлекается.

> Чур меня, чур...

От и я о чем ;)

> Ну протестровали мы парочку ORM. Там когда 15 таблиц мапятца, Perl код какой-то получается, а не вызов.

Ну так не используйте!

ОРМ - он для удобства. В основном используется в несложных приложениях типа вебни.

Если у вас прилада сильно завязана на базу и постоянно случаются хитрые тяжёлые запросы с массой джойнов - лысый SQL вам навстречу.

> под Лисп я такого не встречал,

Да ты офигел. http://clsql.b9.com

Странные люди - не пользовали но ругаем...
def ord_close(request,ord_id):
	"""Закрытие заказа"""
	params=request.GET
	o = OrderHead.objects.get(pk=ord_id)
	o.stClosed=True;
	o.closeDate=datetime.datetime.now()
	o.save()
	return HttpResponseRedirect('/'+site_root+'/ordedit/?id='+ord_id)
В принципе с SQL по количеству строк похоже (за исключением SQL ejection)

def ord_close(request,ord_id):
	"""Закрытие заказа"""
	params=request.GET
        SQL = "update orders set stClose=True, closeDate=now() where id=%s" % int(ord_id)
        c = conn.cursor()
        c.execute(SQL)
	return HttpResponseRedirect('/'+site_root+'/ordedit/?id='+ord_id)

По количеству строк похоже - но сверху читсый питон. а снизу колбаса...

Кстати уже ошибку сделал... надо вместо

SQL = "update orders set stClose=True, closeDate=now() where id=%s" % int(ord_id)

писать

SQL = "update orders set stClose=True, closeDate=now() where id=%i" % int(ord_id)

> Да ты офигел. http://clsql.b9.com

Это для CL, но не для Scheme. Хотя спасибо, что ткнул. Функциональной его частью при нужде воспользуюсь.

> Это для CL, но не для Scheme.

Причем тут схема, ты говорил именно про лисп.

В схеме нет стандартной библиотеки для ООП, о каком ОРМе может идти речь.

> SQL = "update orders set stClose=True, closeDate=now() where id=%i" % int(ord_id)

господи, эти деятели даже используя dbapi умудряются параметры в запросы вдалбливать! вот уж правду говорят, что кривого только могила исправит.

вот поэтому и пользую ОРМ, что для SQL приходится вспоминать что SQL не строка. Кстати для умника (12.07.2007 2:25:31) Нука составь строчку INSERT с использованием DB-API с заранее не известным количеством колонок (например копирование таблицы в таблицу В РАЗНЫХ БД). (Для простоты считаем, что все состоит из строк)

SQL = "INSERT INTO %s ( %s ) VALUES (" % (dest_table, string.join(columns,','))
dest = dconn.cursor()
for row in src.fetchall():
dest.execute(SQL+"%s);" % string.join(list(row),',')))
dest.commit()
--------------------
А вот поди сделай такое без % а только с DB-API (только apply применять).
В итоге если ты DB используешь 5% времени и знаешь про существование paramstyle греха тут нет

> Причем тут схема, ты говорил именно про лисп.

А с каких пор схема не лисп?

>(например копирование таблицы в таблицу В РАЗНЫХ БД)

Лично я бы написал bash script который бы утилитой базы вытакскивал нужную таблицу в dump, а затем также всасывал утилитой в другую базу..

> Нука составь строчку INSERT с использованием DB-API с заранее не известным количеством колонок (например копирование таблицы в таблицу В РАЗНЫХ БД)

слабо представляю себе ситуацию, когда такое необходимо.

> dest.execute(SQL+"%s);" % string.join(list(row),',')))

классических пример sql-injection, даже ни смотря на то, что работать просто не будет - string.join(...,',') должно быть ','.join(...) и значения надо в кавычках слать, если уж ты сам все собираешь, что есть большое зло. а еще надо тогда вручную все значения экранировать. а если там не строки, а, к примеру, юникод или None, то ты вообще попал. не убедил еще?

placeholder = '?' statement = 'insert into %s (%s) values (%s)' % (table, ','.join(columns), ','.join(placeholder * len(columns)) cursor.execute(statement, row)

опять же, это только демонстрация того, как правильно использовать execute. на практике подобные фокусы с динамическими именами таблиц и полей - явный признак плохого дизайна.

вобщем убедил.. только всеравно с ОРМ удобнее чем без него... там вообще насчет таких вещей не думаешь. и не думаешь строка это или SQL

> только всеравно с ОРМ удобнее чем без него... там вообще насчет таких вещей не думаешь. и не думаешь строка это или SQL

разве я против orm что-то сказал? все, что я сказал - это то, что не надо лепить запросы вручную, а оставить подстановку параметров и пр. рутину для execute(). помимо всего прочего, многие реализации умеют компилировать такие шаблоны и использовать их повторно.

с orm надо тоже уметь не переборщить. зачастую, вместо простого "update something set val=val+? where id=?", грузят объект, меняют значение, затем сохраняют.