Python-сообщество

Используем для поиска в таблице конструкцию LIKE при помощи SQLAlchemy:

        contracts = contracts_q.filter(and_(Contracts.nunitcode =='0', Contracts.ncont.like('%'+ncont+'%'), 
                                            Contracts.contract.like('%'+contract+'%')))

Похоже на баг. Регулярка воспринимается как значение поля.

Надо им как-то сказать. Открыть им глаза ))) Неужели никто еще в эту ловушку не попадал.. И в Google ничего на эту тему нет…
Ну… можно конечно устроить пляс с бубном - обработку размера %параметр%, но это уже слишком.

А вообще насколько большое значение имеет SQLAlchemy? Это я к тому, что сейчас пытаюсь использовать сразу напрямую kinterbasdb. Не вылезет ли в дальнейшем что-нибудь вроде того, что аутентификация захочет, чтобы я SA использовал или еще где чего?

Ну если нужен ОРМ - используй SQLAlchemy :) Насколько я помню, ты предпочитаешь работать с базой напрямую через самописные запросы. Насколько я знаю, kinterbasdb API2 совместимо, поэтому и аутентификацию можно делать непосредственно через него.
Да сама структура: DB - DB API (kinterbasdb) - ORM (SQLAlchemy) - Python module вполе позволяет исключить ORM-звено.

1) Есть возможность посмотреть какой запрос генерит твой ОРМ?
2) Когда-то я стыкался с таким глюком и это был глюк ФБ - там была проблема с кодировкой. Решилось редактированием строки.

Вот сообщение, там и сгенеренный запрос:

ProgrammingError: (ProgrammingError) (-802L, "String overflow: value 6 bytes long cannot fit in character field of maximum length 4 (value is '%1111%').") 'SELECT count(1) AS count_1 \nFROM "CONTRACTS" \nWHERE "CONTRACTS".nunitcode = ? AND "CONTRACTS".ncont LIKE ? AND "CONTRACTS".contract LIKE ?' ['0', u'%1111%', u'%%']

baloo
А вот ссылка на мой трэйсбэк отправленный
http://pylonshq.com/tracebacks/7ece2e82675ea737f24e0aade09fbd6a

Пожаловался разработчику. Вот ответ от Pavel Cisar:

There is a difference in SQLAlchemy code and your test code. Beside that
SQLAlchemy uses parametrised statement (with ?) while your code does
not, more importantly SQLAlchemy statement uses UNICODE string for
parameter value while your test code does not (it uses UTF-8 thought).

KInterbasDB should handle automatic UNICODE/charset conversion for you,
but it has to be properly set. The key here is the CONNECTION charset
(database charset is about storage encoding, connection charset is about
how you'll pass / get values to / from your application. KInterbasDB has
also several modes for automatic translations controlled by
kinterbasdb.init(type_conv=<value>) call. See KInterabsDB documentation
for details.

Ну я, конечно, had saw всю эту документацию, там есть опции автоматической конвертации в KInterbasdb. Попробовал менять их, отключать - никакой разницы. Вообще я бы отказался от SQLAlchemy, поскольку предпочитаю работать с обычными запросами. Единственное, что мне нравится - так это как SQLAlchemy взаимодействует с Paginator'ом. Ведь для того, чтобы паджинатор посчитал страницы и пр., по-любому требуется запросить весь запрос. Проще говоря, прменение rows так или иначе запрашивает ВСЕ, а потом из него берет свое. Получается долго. А алхимия делает как-то быстро и элегантно, даже запрос в 60 тысяч срок делит за секунду. Пытался отследить как, но пока ума не хватило.

Кстати, склепал на скорую руку аналог моей FireBird-овской таблицы на SQLite, работает!!! То-есть, слабое звено… я бы не сказал, что все-таки в KinterbasDB, а как бы во взаимодействии его и алхимии :(

baloo
Вообще я бы отказался от SQLAlchemy, поскольку предпочитаю работать с обычными запросами. Единственное, что мне нравится - так это как SQLAlchemy взаимодействует с Paginator'ом. Ведь для того, чтобы паджинатор посчитал страницы и пр., по-любому требуется запросить весь запрос. Проще говоря, прменение rows так или иначе запрашивает ВСЕ, а потом из него берет свое. Получается долго. А алхимия делает как-то быстро и элегантно, даже запрос в 60 тысяч срок делит за секунду. Пытался отследить как, но пока ума не хватило.

SELECT COUNT(*) ...
потом
SELECT FIRST x SKIP y ...