Как тут сделать insert?

Question

[Глеб Лукашонок]

Всем привет! Использую python+firebird. Хочу создать новую запись в таблице

В таблице есть тригер на генерацию ID и даты:

AS
BEGIN
 if(new.id is null) then new.id=gen_id(d_gen_commands,1);
 new.datetime="now";
 post_event "d_new_command";
END

---------------------

cur.execute(f"insert into d_commands values {(num, date_and_time, 1, 'open_door,0', -1062731554)}")

Мой код выше полностью работает, но мне надо не 5 значений вписывать, а только 3 из них.

И вот моё решение:

cur.execute(f"insert into d_commands (executor, text, phis_addr) values ({int(1)}, {str(action)}, {int(-1062731554)})")

да, может с *int* и *str* не красиво выглядит, но я уже отчаялся что "мало-ли"... Всё что нашел - перепробовал, поэтому я тут :) Выдаёт следующую ошибку:

('Error while preparing SQL statement:\n- SQLCODE: -206\n- Dynamic SQL Error\n- SQL error code = -206\n- Column unknown\n- OPEN_DOOR\n- At line 1, column 63', -206, 335544569)

Ещё где-то вычитал что при моём динамическом запросе надо вручную вызывать триггер из начала поста. Не знаю правда или нет и не знаю как xD
Подскажите пожалуйста как решить эту проблему. Спасибо!

Comments

[Akina]

Подставляемое значение {str(action)} имеет строковый тип, но не обрамлено кавычками, и сервер воспринимает его не как строковый литерал, а как имя поля - а поля с таким именем не существует.

Пробуй так:

cur.execute(f"insert into d_commands (executor, text, phis_addr) values ({int(1)}, '{str(action)}', {int(-1062731554)})")

[Глеб Лукашонок]

Akina, спасибо огромное, помогло! :) Не могу только понять как отметить ваше решение ответом.

[Akina]

Глеб Лукашонок, никак не отмечать... то, что Вы не обрамили строковый литерал кавычками - обычно интерпретируется как опечатка (другие варианты - более обидны).

А вот то, что Вы собираете строку запроса прямо в cur.execute - вот это бардак. Если бы Вы сперва в отдельной переменной собрали SQL-текст, а потом другой командой выполнили SQL-запрос, то посередине могли бы вывести текст запроса "на посмотреть" - и суть проблемы, равно как и метод лечения, был бы совершенно очевиден.

Answer 1

[Vindicar]

Akina, Глеб Лукашонок, пожалуйста, не собирайте SQL запросы с помощью форматирования строк без крайней на то необходимости.

Используйте placeholders, и да пребудет с вами Бобби Тейблз.

cur.execute("insert into d_commands (executor, text, phis_addr) values (?, ?, ?)", (1, str(action), -1062731554))

В этом случае экранирование будет выполнено автоматически, без риска что вы забудете это сделать.

Comments

[Akina]

не собирайте SQL запросы с помощью форматирования строк без крайней на то необходимости.

Оно, конечно, правило-то хорошее - но не абсолютное.
Если при сборке запроса не используется пользовательский ввод - то не вижу никаких противнопоказаний.

В данном конкретном случае, как я понимаю, в текст запроса подставляется предопределённый литерал, жёстко прописанный константой в коде приложения. Как раз тот самый случай-исключение.

[Vindicar]

Akina, если используется литерал, то запрос можно и захардкодить без форматирования.
А если это значение откуда-то получается, то это мало чем отличается от пользовательского ввода. Не говорю уж про ситуацию, когда ранее захардкоженное значение рефакторится в пользовательский ввод без исправления способа формирования запроса.
Так что тут лучше перебдеть чем недобдеть.
По мне так есть только три сценария для ручного формирования запроса: кастомный поиск (по заранее неизвестному набору условий), кастомный порядок сортировки, и использование оператора IN со списком заранее неизвестного размера (последний случай тоже реализуется через плейсхолдеры, но без синтеза запроса не обойтись).

[Akina]

Vindicar,

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

Да ладно... чем плоха такая конструкция:

parameter = CASE user_input()
                WHEN BETWEEN 0 AND 9 THEN 'LOW'
                WHEN BETWEEN 10 AND 99 THEN 'MIDDLE'
                WHEN BETWEEN 100 AND 999 THEN 'HIGH'
                ELSE 'INCORRECT' END

и последующее использование parameter в качестве параметра запроса? да, по пользовательскому вводу - но все возможные значения захаркодены.

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

Ну тут уж каждый сам куец своего /*счастья*/ геморроя. Нельзя так мелко рефакторить.

лучше перебдеть чем недобдеть.

Вот тут возразить нечего.

[Глеб Лукашонок]

Akina, Vindicar, так как лучше\правильнее делать такие запросы? У меня этот запрос обёрнут функцией и параметры в неё передаются каждый раз - разные значения. Единственное что str и int на входе постоянны. Тогда лучше собирать конструкцию отдельно и писать execute(command)? Поправьте если не прав. В любом случае спасибо вам за помощь!

[Vindicar]

Глеб Лукашонок, можешь использовать мой вариант. Тогда всеми вопросами экранирования займётся прослойка работы с БД, и тебе не придётся помнить "а можно ли в эту функцию передавать параметры с апострофами?"