Список python в запросе sql как параметр

Поскольку этот подход не использует подстановку параметров базы данных, он подвергает вас атакам с использованием SQL-инъекций. Используемый здесь % представляет собой простое форматирование строки Python.

:-( Привязка Python SQLite не поддерживает последовательности.

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

Извините, я не предлагаю и не подразумеваю SQLite - просто грустно, что привязки для списков там не работают.

@Thiefmaster: да, в общем случае это должен быть ([placeholder]*len(l)), поскольку заполнитель может состоять из нескольких символов.

@bobince в моем случае я назначил переменную a = 'john' и b = 'snow' и сохранил ее в кортеже с именем got = ['a, b'] и выполнил тот же запрос. При этом я получил ошибку, т.е. ошибку типа: не все аргументы преобразованы во время форматирования строки. Как я должен это решить?

Почему вы хотите присоединиться «вручную», а не оставлять эту работу dbapi? ключ в том, чтобы использовать кортеж, а не список ...

@AlessandroDentella, sqlite его не поддерживает. пример явно добавляет ? в предложение INSERT, которое аналогично предложению IN.

Да, передача кортежа в качестве параметра - это то, что не является стандартной функцией DB-API, и для %-paramstyle это, вероятно, не делает то, что вы думаете - это на самом деле вызывает str в кортеже и вставляет репозиторий Python в Строка запроса. Это работает, когда это кортеж из как минимум двух целых чисел, каждое из которых должно быть слишком маленьким, чтобы получить суффикс L. Он не работает в большинстве других случаев - и, в частности, не работает для строковых литералов, что делает его уязвимостью SQL-инъекций. Не делай этого!

У меня есть список повторяющихся данных, которые должны быть переданы как список заполнителей, но sql выполняется только как установлено

На основе этого ответа предлагается однострочное решение для Python 3.6cursor.execute(f'SELECT name FROM students WHERE id IN ({','.join('?' for _ in l)})', l). @bobince, вы также должны отметить в своем решении, что использование ? - это безопасный способ избежать SQL-инъекций. Здесь много уязвимых ответов, в основном те, которые объединяют строки в python.

@roganjosh, согласен, и на самом деле ошибается: cursor.execute(f"SELECT name FROM students WHERE id IN ({','.join('?' for _ in l)})", l). К сожалению, вариантов не так много, если вы хотите избежать SQL-инъекции, я бы разделил одну строку на несколько 2 или 3. В этом случае одна строка удобна в качестве примера того, как использовать Python f-strings. В исходном ответе третья строка будет выглядеть так: query= f'SELECT name FROM students WHERE id IN ({placeholders})'.

@bobince Можно ли подробнее рассказать о комментарии, «все из которых должны быть слишком маленькими, чтобы получить суффикс L. Он не работает в большинстве других случаев - и, в частности, не работает для строковых литералов, что делает его уязвимостью для SQL-инъекций» ?

@LeiHao В Python 2 число с суффиксом L, например 98L, является длинным целым числом. Если число слишком велико, чтобы быть коротким целым числом, например 80000000000, то repr() возвращает значение с суффиксом L. Python 3 никогда этого не делает, потому что целочисленный тип полностью обрабатывает его. Python 3.

что, если мне нужно передать дополнительный параметр вместе со списком l в запросе. query= 'SELECT name FROM students WHERE id IN (%s) and name= %(name)s' % placeholders ??

Это не лучшее решение из-за внедрения sql.

Это не сработает, если l содержит только один элемент, вы получите id IN (1,). Это синтаксическая ошибка.

Если это только один элемент, IN - это не тот оператор, который вам нужен. OP явно не делает; t.

Если l содержит только 1 элемент, убедитесь, что это кортеж, и он БУДЕТ работать. На мой взгляд, это решение более ясное, чем принятое.

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

Некоторые соединители баз данных (например, соединение pyodbc с SQL Server) не поддерживают именованные параметры, поэтому это не всегда сработает.

У меня это не работает с sqlite3. С какой библиотекой вы это тестировали?

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

Хорошее решение, но @renstrm и Никита-Конин правы, требуя дополнительных проверок, когда в кортеже есть один элемент или нет элементов.

Это правильный ответ. Использую красное смещение и панды, вот оно: pd.read_sql_query(sql='select * from table where id in :ids_tuple', con=..., params = {'ids_tuple':l}); Очень удобно. и вы можете заменять списки идентификаторов в цикле без перекомпиляции запроса.

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

Это настоящий ответ.

Согласен, это лучший ответ!

Красиво и чисто!

Как указано в @renstrm, это не сработает, если l содержит только один элемент, вы получите id IN (1,). Это синтаксическая ошибка.

если у вас только один элемент, вам не нужно использовать IN. вы можете просто сделать =

@Amirhos Imani, а что, если вы не знаете, сколько элементов у вас есть?

@Boris, если вы не можете гарантировать, что ваш ввод всегда является списком, вы можете сделать что-то похожее на этот лайнер stackoverflow.com/questions/38821586/…, прежде чем передавать аргумент вашему запросу

Это, как и большинство ответов здесь, кроме принятого, уязвимо для SQL-инъекции и не должно использоваться.

@BaconBits Справедливое предупреждение, но для некоторых приложений, где SQL-инъекция не является проблемой (например, анализ базы данных, в которой я единственный пользователь), это подойдет.

да, это не работает для одного элемента, просто понял

Моя проблема заключалась в параметризованных запросах. Введенный параметр списка всегда заканчивал тем, что его значения были заключены в кавычки в результирующих предложениях SQL IN, что чертовски сбивало с толку. Идея tuple() сработала. Это работает, потому что DJango переводит это в строковый формат, подходящий для предложения SQL IN(). Именно это меня не поразило, когда в нескольких ответах предлагалось использовать tuple.