Приветствую всех! Столкнулся с одной проблемкой при работе с Firebird и с использованием библиотеки питоновской библиотеки fdb. Суть проблемы также описал на стэковерфлове . Продублирую это и здесь. Обратите внимание на код ниже:




Обратите внимание, что все что поменялось - это еще одна подготовленная переменная (prepared variable) после слова ELSE в запросе. Причем, что странно Питон не ругается на аналогичную переменную поле ключевого слова THEN. В чем тут проблема и почему так происходит сам не смог разобраться. Рассчитываю на вашу помощь, форумчане. Мерси!

Это у вас такой тонкий юмор про телепатический модуль? Согласно по fdb документации никакого явного каста не нужно делать. Да и с точки зрения приложения - это самоубийство. Потому что одно дело везде использовать старые добрые ?, а другое проверять каждую переменную. Значит все-таки я был прав по поводу bullshit? Бага в fdb?

А где логика в том, что




работает, а




не работает?

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




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

Не вижу проблемы.

Со строкой в тысячу символов тоже все норм. Так что не вижу повода для веселья.

Тоже все в порядке:

Минуту. Не то сделал.

Вообще-то у меня такой цели нет. Можешь обратить внимание, что я не констатировал баг, а спрашивал баг ли это. Куда больше меня интересует причина того, что происходит именно так. Я смотрю документацию и вижу в ней одно, а вы даете совершенно другую рекомендацию, противоречащую документации. Вы всячески не обращаете внимание на то, что я даю ссылки на документацию. Вот не ссылка, а цитата:

автор
Parametrized statements

When SQL command you want to execute contains data values, you can either:

Embed them directly or via string formatting into command string, e.g.:

cur.execute("insert into the_table (a,b,c) values ('aardvark', 1, 0.1)")
# or
cur.execute("select * from the_table where col == 'aardvark'")
# or
cur.execute("insert into the_table (a,b,c) values ('%s', %i, %f)" % ('aardvark',1,0.1))
# or
cur.execute("select * from the_table where col == '%s'" % 'aardvark')

Use parameter marker (?) in command string in the slots where values are expected, then supply those values as Python list or tuple:

cur.execute("insert into the_table (a,b,c) values (?,?,?)", ('aardvark', 1, 0.1))
# or
cur.execute("select * from the_table where col == ?",('aardvark',))

While both methods have the same results, the second one (called parametrized) has several important advantages:

You don’t need to handle conversions from Python data types to strings.
FDB will handle all data type conversions (if necessary) from Python data types to Firebird ones, including None/NULL conversion and conversion from unicode to byte strings in encoding expected by server.
You may pass BLOB values as open file-like objects, and FDB will handle the transfer of BLOB value.
If you’ll pass exactly the same command string again to particular Cursor instance, it will be executed more efficiently (see section about Prepared Statements for details).

Parametrized statemets also have some limitations. Currently:

DATE, TIME and DATETIME values must be relevant datetime objects.
NUMERIC and DECIMAL values must be decimal objects.




Обращаю внимание на то, что the second one (called parametrized) has several important advantages и на то, что второй вариант имеет ряд ограничений, но ни одно из них не касается строк. Получается, что документация не актуальна на все сто? Если нет, как бы вы сформулировали в ней тот нюанс, о котором я задал вопрос и объяснили, ПОЧЕМУ в данном случае использование маркера ? не является предпочтительным. К настоящему моменту я просто не услышал солидного аргумента и объяснения (толстые намеки не в счет).

Благодарю, dimitr! Теперь все встало на свои места. Хотя подобное поведение удручает, так как в MySQL, SQLite, Postgres, Oracle и MSSQL подобная параметризация запроса работает, как и ожидаешь. Ну и сам вывод типа параметра ELSE по THEN, вы уж меня извините, кроме как бредом я не назову. (IMHO, сугубо субъективно и естественно не претендует на какую-то истину)

Хотя минутку, dimitr. Как же такой алгоритм вывода типа параметра объясняет ошибку, которая вылетает на последнем примере IBExpert?

Dimitry Sibiryakov Вышеназванные сервера даже не пытаются определять тип параметра.

Вообще-то это не так или во всяком случае не совсем или не всегда так. Если взять тот же Оракл, то он не то что будет пытаться определить тип параметра, но может сделать implicit cast, и выдать ошибку в случае, если типы не совпадают, как, например, в этом случае:

[code]

select id from test_table WHERE id = :id

[code]

Если id имеет тип NUMBER, а в качестве параметра передадите какую-нибудь строку, то Оракл попробует привести эту строку к NUMBER и выкинет соответственно ошибку.

Еще раз медленно: в том примере, что я привел Оракул (цитата) "пытается определять тип параметра" как NUMBER и выдает ошибку, если в качестве параметра передается какая-нибудь строка. Аналогичный запрос например в MySQL и Postgres уже к ошибке не приводит, потому что они (цитата) "даже не пытаются определять тип параметра". Поэтому то, что ты сказал (в том смысле, как я это понял), не обобщается на все (цитата) "вышеназванные сервера". НО. Я не исключаю, что мог понять этот комментарий не так как следует, и для этого может потребоваться тогда расшифровать что значит (цитата) "получить от ... тип параметра запроса" - можно на примере того же Firebird. А вообще поднятая в топике проблема решена и требует дальнейших объяснений.

*не требует.