forum.opennet.ru - "Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода" (66)

"Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода"	+/–
Сообщение от opennews (??), 04-Июл-22, 15:32
Опубликованы корректирующие выпуски web-фреймворка Django 4.0.6 и 3.2.14, в которых устранена уязвимость (CVE-2022-34265), потенциально позволяющая выполнить подстановку своего SQL-кода. Проблема затрагивает приложения, использующие непроверенные внешние данные в параметрах kind и lookup_name, передаваемых в функции Trunc(kind) и Extract(lookup_name). Программы, которые допускают в значениях lookup_name и kind только проверенные данные уязвимость не затрагивает... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57452
Ответить \| Правка \| Cообщить модератору

Оглавление

просто используешь построитель запросов и все Но нет, давайте клеить sql-строку, Аноним (1), 15:32 , 04-Июл-22, (1)

Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижд, Без аргументов (?), 15:50 , 04-Июл-22, (4) –6

У меня конструкции вида select func max text cast key as integer ,text valu, Аноним (6), 16:06 , 04-Июл-22, (6) –7

Кстати, там то же самое рядом через ORM, если это зло и намного хуже, то я даже , Аноним (6), 16:11 , 04-Июл-22, (8) –2

везде нифига не понятно интересно, как это будет работать, если строк миллион а, Без аргументов (?), 19:54 , 04-Июл-22, (25)

Прекрасно это работает Откуда там миллиону взяться, если поле с жсоном обновляе, Аноним (6), 20:19 , 04-Июл-22, (31)

Вот так и начинаются кадастрофы , ПерлухаБратуха (?), 04:46 , 05-Июл-22, (48)

В данном случае это костыль, позволяющий избежать бессмысленного усложнения схем, Аноним (6), 13:44 , 05-Июл-22, (53)

max int k for k in self relations - это какая-то хитрая чёрная магия Или про, Онаним (?), 22:11 , 04-Июл-22, (39)

Но если к max надо ещё условие присандалить, то будет получаться шиза вида sel, Онаним (?), 22:13 , 04-Июл-22, (40)
Это именно получение последнего по времени объекта из жсона, с ним можно работат, Аноним (6), 22:45 , 04-Июл-22, (43)

Я ничего тут не понял что там у вас про JSON Я говорю про человеческую нормализ, Без аргументов (?), 19:52 , 04-Июл-22, (24)

Да не, тут нормально всё Это json в sqlite, надо получить последнюю по времени , Аноним (6), 20:16 , 04-Июл-22, (30)

Ну я же говорю, что это детский садик Другое дело когда у вас оракл и 120ГБ ОЗУ, Без аргументов (?), 00:03 , 05-Июл-22, (45)

Так если бы там были какие-то данные, я бы как минимум не стал использовать жсон, Аноним (6), 00:11 , 05-Июл-22, (46)

ОРМ нужен не для того чтобы неадекватную архитектуру покрывать Если кто-то модел, GG (ok), 10:53 , 05-Июл-22, (49) –2

Хех, но ведь это же вообще не имеет отношения к ORM, претензия должна быть к SQL, Аноним (6), 14:39 , 05-Июл-22, (55)

На практике в нормализованных БД слишком много джойнов, даже если это база микро, Аноним (56), 03:13 , 06-Июл-22, (56) +1

Ха Да Дальше второй формы уходить - это уже для особых случаев Когда не жалко, Онаним (?), 00:03 , 08-Июл-22, (67)

Глаза чутка подвытекли Я уж за производительность этого добра даже не переживаю , Онаним (?), 22:07 , 04-Июл-22, (37) +1

Кстати, с производительностью всё удивительно хорошо в итоге Ну и оно же кэширу, Аноним (6), 22:52 , 04-Июл-22, (44)

Хотя конечно после cast key as integer там уже точно ничего не страшно, Онаним (?), 22:07 , 04-Июл-22, (38) +1
особенно тут , Аноним (61), 19:50 , 06-Июл-22, (61)

Разве что, чуточку Но в SQL это выглядело не лучше и позволяло выполнить подста, Аноним (6), 20:08 , 06-Июл-22, (62)

Не понял, ты на код глазами смотришь или чем Про возможность эскейпинга подстав, Аноним (68), 17:02 , 09-Июл-22, (68)

Да, я, например, хочу строить запросы одинаково на любом рантайме , Аноним (66), 18:38 , 07-Июл-22, (66)

Опять все путают ORM и Query Builder ORM нужна для того, чтобы автоматически орг, Аноним (7), 16:09 , 04-Июл-22, (7) +3

Вот весь прикол в том, что аналитические запросы есть смысл класть на нормальную, kai3341 (ok), 19:29 , 04-Июл-22, (18)

Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя , Аноним (19), 19:41 , 04-Июл-22, (19)

Пользуясь случаем, о каком двустороннем маппинге речь Об ActiveRecord Если да,, kai3341 (ok), 19:48 , 04-Июл-22, (23)

Поскольку тормозит применительно к питону - это его естественное состояние, всё , Онаним (?), 22:16 , 04-Июл-22, (41) –1

Давно уже есть, просто довольно нетривиально, GG (ok), 10:56 , 05-Июл-22, (50) –1

Меня тоже бомбило, но потом я попробовал алхимию https habr com ru post 55973, kai3341 (ok), 16:16 , 04-Июл-22, (9) –3

Если выходит плюс минус так же, зачем Чтобы что В базу оно все равно пойдет в , Аноним (12), 17:30 , 04-Июл-22, (12)

Как думаете, зачем я дал ссылку на статью Ответ -- в ней ответы на заданные вам, kai3341 (ok), 18:19 , 04-Июл-22, (13) –2

Расскажи пожалуйста подробно, зачем ты делаешь сложные операции Ты не думал что, Аноним (11), 16:53 , 04-Июл-22, (11) +2

Я работал разработчиком BI-отчетов и витрин данных Там на первом месте оптимиза, Без аргументов (?), 19:45 , 04-Июл-22, (20)

Вон из профессии, GG (ok), 10:57 , 05-Июл-22, (51) –3

Вся эта шелуха работает до тех пор, пока проект более менее не вырастет в большу, Без аргументов (?), 19:57 , 04-Июл-22, (27) –1

Но-но, у нас тут хайлоад, кек Орм в первую очередь, про удобство взаимодействия, Аноним (6), 20:51 , 04-Июл-22, (32)

Народ ныне очень любит ORM отрывать от логики объектов, превращая его в прослойк, Онаним (?), 21:59 , 04-Июл-22, (35) +2

Если у тебя набор данных сложнее товаров для витрины превращается в непроходимую, GG (ok), 11:00 , 05-Июл-22, (52) –1

Пока у тебя да, полтора товара на витрине, как правильно указали - тебе пойдёт и, Онаним (?), 22:03 , 04-Июл-22, (36)

А каким образом Вы боретесь с уязвимостями типа sql-иньекция , Аноним (17), 18:56 , 04-Июл-22, (17)

Проверить входные параметры, чтобы без точек с запятой и т п А вообще изкоробки, Без аргументов (?), 19:46 , 04-Июл-22, (21)

Любой драйвер БД умеет в подстановку значений Я рекомендую читать документацию, kai3341 (ok), 20:05 , 04-Июл-22, (28)

Нифига сколько неосиляторов в SQL минусонуло Ну я тоже с трудом въезжал Пока н, Без аргументов (?), 19:56 , 04-Июл-22, (26) –1

Не в этом дело, мне кажется Просто, комментатор слишком уж категоричен Ну и по, Аноним (6), 21:00 , 04-Июл-22, (33)

Ды не, ORM своё место Тут стоит для начала вернуться к тому, что ORM от SQL-inj, Онаним (?), 22:19 , 04-Июл-22, (42) +1

Скрыто модератором, васёк (?), 15:36 , 04-Июл-22, (2) –1

Скрыто модератором, Корец (?), 15:46 , 04-Июл-22, (3) +1
Скрыто модератором, Без аргументов (?), 15:51 , 04-Июл-22, (5)

Тест на имбецила в 21 веке Если такая ошибка находится, СРАЗУ же в отдел кадров, Аристарх (??), 18:46 , 04-Июл-22, (14) –2

Соглы , Без аргументов (?), 19:47 , 04-Июл-22, (22) +1

А как это можно использовать Не совсем понятно, куда нужно вбивать свой СКУЛь , Sergey (??), 18:46 , 04-Июл-22, (15)

В эксплоит Эксплоит тебе придеться купить , Аноним (63), 14:41 , 07-Июл-22, (63)

Нужно использовать подготовленные выражения и тогда sql-иньекции станут невозм, Аноним (17), 18:49 , 04-Июл-22, (16) +1
затонеphp tm Суть та же, криворучки - они повсюду , Онаним (?), 20:10 , 04-Июл-22, (29) –1
Sql injection в 2022 Достижение , Аноним (34), 21:51 , 04-Июл-22, (34) +1

Достижение, что наконец-то лидерство какого-то говнянеького фреймворка начинает , Аноним (63), 14:43 , 07-Июл-22, (64)

Перечисленные методы в нормальных руках при нормальных мозгах никогда не будут, Аноним (47), 04:32 , 05-Июл-22, (47) +1
А раст может как-то помочь Или в расте такие же дыры , Аноним (61), 14:06 , 05-Июл-22, (54)

От ошибок в бизнес-логике раст тоже не защитит Только от гонок и некоторых видо, Аноним (56), 03:25 , 06-Июл-22, (57)

Пока вебрендера не было, синхронизация вкладок не отваливалась , Аноним (6), 03:47 , 06-Июл-22, (58) +1

Ратс не нужен забудь про него плз , Аноним (60), 17:45 , 06-Июл-22, (60) +1

Так его так и не доснимали же , Аноним (63), 14:49 , 07-Июл-22, (65)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 04-Июл-22, 15:32 +/–

просто используешь построитель запросов и все. Но нет, давайте клеить sql-строку самому.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

2. Сообщение от васёк (?), 04-Июл-22, 15:36 –1 +/–

и питоша тоже? я думал только Сишка дырявая

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #5

3. Сообщение от Корец (?), 04-Июл-22, 15:46 +1 +/–

>я думал только Сишка дырявая
Не переживай, дырявым может быть код на любом языке. Даже на том самом ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

4. Сообщение от Без аргументов (?), 04-Июл-22, 15:50 –6 +/–

Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6, #7, #9, #11, #17, #26, #42

5. Сообщение от Без аргументов (?), 04-Июл-22, 15:51 +/–

А у тебя минимум 4 дырки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Аноним (6), 04-Июл-22, 16:06 –7 +/–

У меня конструкции вида select(func.max(text("cast(key as integer)")),text('value')).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'")) всё норм, ничего не бомбит. Легко читается, даже легче, чем чисто sql. Вы что-то делаете не так.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #8, #24, #37, #38, #61, #66

7. Сообщение от Аноним (7), 04-Июл-22, 16:09 +3 +/–

Опять все путают ORM и Query Builder.
ORM нужна для того, чтобы автоматически организовать как сохранение данных дерева объектов в РСУБД, так и восстановление их из сохраненных в РСУБД данных в память. Такая своего рода сериализация, только в РСУБД, что позволяет эффективно организовать поиск по данным.
Query Builder нужен преимущественно как часть ORM для построения запросов для поиска нужных объектов в базе. При использовании Query Builder совместно с ORM важно, что они друг с другом интергрированы, и в качестве результата будут получены не сырые данные из базы, а нужный объект (или коллекция) со всеми вложенными объектами-коллекциями.
Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). Query Builder-ы иногда полезны, если запрос строится в зависимости от данных, запрошенным пользователем - без них довольно неудобно собирать запрос по частям (что-то в select, что-то в join, что-то в where и т.д.). Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy. С более примитивными QB, которые разработаны как вспомогательные части для ORM, будет проще генерировать запрос вручную.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #18, #50

8. Сообщение от Аноним (6), 04-Июл-22, 16:11 –2 +/–

Кстати, там то же самое рядом через ORM, если это зло и намного хуже, то я даже не знаю ем тут помочь.
maxvalue = max([int(k) for k in self.relations])
return (maxvalue, self.relations[str(maxvalue)],)
а вот это orm-sql
return select(func.max(text("cast(key as integer)"))).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'"))
ну и где читаемее?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #25, #39

9. Сообщение от kai3341 (ok), 04-Июл-22, 16:16 –3 +/–

> Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.
Меня тоже бомбило, но потом я попробовал алхимию: https://habr.com/ru/post/559738/
Выходит плюс/минус тот же самый синтаксис

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #12

11. Сообщение от Аноним (11), 04-Июл-22, 16:53 +2 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #20, #27, #36

12. Сообщение от Аноним (12), 04-Июл-22, 17:30 +/–

Если выходит плюс минус так же, зачем? Чтобы что? В базу оно все равно пойдет в виде запроса. Лишь бы не писать SQL?
Из той же серии билдеры регулярных выражений (не путать с грамматиками). Иррациональный страх перед технологиями отцов-основателей? Своё лучше пахнет и делает волосы мягче и шелковистее?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13

13. Сообщение от kai3341 (ok), 04-Июл-22, 18:19 –2 +/–

Как думаете, зачем я дал ссылку на статью? Ответ -- в ней ответы на заданные вами вопросы и некоторые ещё не заданные

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

14. Сообщение от Аристарх (??), 04-Июл-22, 18:46 –2 +/–

> подстановку своего SQL-кода
Тест на имбецила в 21 веке. Если такая ошибка находится, СРАЗУ же в отдел кадров на увольнение по собственному!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22

15. Сообщение от Sergey (??), 04-Июл-22, 18:46 +/–

А как это можно использовать ? Не совсем понятно, куда нужно вбивать свой СКУЛь запрос ;(

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #63

16. Сообщение от Аноним (17), 04-Июл-22, 18:49 +1 +/–

Нужно использовать "подготовленные выражения" и тогда sql-иньекции станут невозможны.

Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (17), 04-Июл-22, 18:56 +/–

А каким образом Вы боретесь с уязвимостями типа "sql-иньекция"?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #21

18. Сообщение от kai3341 (ok), 04-Июл-22, 19:29 +/–

> Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга).
> Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy
Вот весь прикол в том, что аналитические запросы есть смысл класть на нормальную ORM типа алхимии (DjangoORM говно). Так как статью (ниже) читать дело не царское, скажу тут. ORM позволяет сделать SQL-запрос модульным, позволяет повторно переиспользовать код через наследование или композицию. Также адекватная ORM умеет в вывод типов. Алхимия позволяет также реализовывать макросы, что удачно сочетается с выводом типов.
Ещё раз для тех, что не умеет читать: чмORM типа той же djangoORM дают преимущества только на простейших запросах (CRUD), но на аналитике дрыщут в лужу. Адекватные ORM типа алхимии дают как преимущества на банальном CRUD, так и на аналитике.
Ну и таки шо по производительности? Если верхний мозг не использовать, то алхимия тормозит, джанга чуть меньше тормозит. Если верхний мозг в наличии, то небольшие тормоза получаем на этапе инициализации, но в рантайме производительность мало отличается от raw sql. Вопросу уделено особое внимание в статье
А ещё про миграции никто не рассказал

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #19, #41

19. Сообщение от Аноним (19), 04-Июл-22, 19:41 +/–

Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам нет, не совсем корректно называть это ORM.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23

20. Сообщение от Без аргументов (?), 04-Июл-22, 19:45 +/–

Я работал разработчиком BI-отчетов и витрин данных. Там на первом месте оптимизация и скорость выполнения. Как выше написали, ORM/QB детский садик работает для примитивных CRUD. Насчет мапинга не скажу, что удобнее. Точнее мапинг можно и из сырого запроса сделать без всякого блоатваре.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #51

21. Сообщение от Без аргументов (?), 04-Июл-22, 19:46 +/–

Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще изкоробки обычно есть постановка параметров (через ???), которая проверяет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #28

22. Сообщение от Без аргументов (?), 04-Июл-22, 19:47 +1 +/–

Соглы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

23. Сообщение от kai3341 (ok), 04-Июл-22, 19:48 +/–

> Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую
> гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам
> нет, не совсем корректно называть это ORM.
Пользуясь случаем, о каком двустороннем маппинге речь? Об ActiveRecord? Если да, то где он вообще есть для такого типа запросов?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

24. Сообщение от Без аргументов (?), 04-Июл-22, 19:52 +/–

Я ничего тут не понял что там у вас про JSON. Я говорю про человеческую нормализованную СУБД.
Но сразу виду обезьянокод. Какие-то двойные преобразования типов из текста в число. И еще макс можно сделать в одном запросе без вложения.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #30, #56

25. Сообщение от Без аргументов (?), 04-Июл-22, 19:54 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #31

26. Сообщение от Без аргументов (?), 04-Июл-22, 19:56 –1 +/–

Нифига сколько неосиляторов в SQL минусонуло. Ну я тоже с трудом въезжал. Пока не научился делать пятэтажные запросы и такие, и сякие, с динамической группировкой и фильтрами на тысячу строк кода. А бывает, когда в СУБД надо передать хинты, т.к. оптимизатор не экстрасенс на все случаи жизни

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #33

27. Сообщение от Без аргументов (?), 04-Июл-22, 19:57 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #32, #52

28. Сообщение от kai3341 (ok), 04-Июл-22, 20:05 +/–

> Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще
> изкоробки обычно есть постановка параметров (через ???), которая проверяет.
Любой драйвер БД умеет в подстановку значений. Я рекомендую читать документацию

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

29. Сообщение от Онаним (?), 04-Июл-22, 20:10 –1 +/–

затонеphp(tm)
Суть та же, криворучки - они повсюду.

Ответить | Правка | Наверх | Cообщить модератору

30. Сообщение от Аноним (6), 04-Июл-22, 20:16 +/–

Да не, тут нормально всё. Это json в sqlite, надо получить последнюю по времени запись из поля с жсоном, ключи в котором принудительно конвертируются в текст, а значит, последнее значение из текстового ключа не получить. Я это к тому, что даже если ORM не позволяет решить не стандартную задачу адекватно (вставки text), это всё ещё вполне прилично выглядит в результате, куда лучше чем голый зубодробительный sql с сотней уязвимостей на запрос.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #45, #49

31. Сообщение от Аноним (6), 04-Июл-22, 20:19 +/–

Прекрасно это работает. Откуда там миллиону взяться, если поле с жсоном обновляется пару раз в месяц? Причём, используется всегда только последнее значение, старые данные остаются для истории. Тут никаких проблем быть не может.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #48

32. Сообщение от Аноним (6), 04-Июл-22, 20:51 +/–

Но-но, у нас тут хайлоад, кек. Орм в первую очередь, про удобство взаимодействия с данными. У тебя есть инстанс чего-то, у него есть отношения с другими инстансами чего-то, на эти инстансы по различным правилам мапятся данные из таблиц, при совершении определённых операций могут случатся всевозможные полезные вещи с зависимостями в других таблицах. Когда он больше не нужен, он автоматически удаляешься из сессии (и её кэша).
Если шпарить sql, довольно быстро свихнёшься, а баги ловить ещё то удовольствие. Хотя ВЫГЛЯДИТ оно куда проще, ага. Стоимость намного выше в итоге, а ошибок и уязвимостей больше, сопровождение и доработка часто превращаются в практически не решаемую проблему.
Если, конечно, задача примитивная, там чем проще тем лучше, но когда связей много, или много условий, что и когда подгружать (у записи много данных, которые не нужны при наиболее частых обращениях) и обновлять, тут без орм никуда.
Я бы не стал прям так демонизировать орм, у этого подхода есть большой спектр задач, которые он способен решать весьма эффективно. В принципе, та же алхимия, может использоваться и без орм, если производительность и эффективность прямо так важны (что крайне маловероятно на практике), всё ещё остаётся много хорошего, что в ней есть помимо него.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #35

33. Сообщение от Аноним (6), 04-Июл-22, 21:00 +/–

Не в этом дело, мне кажется. Просто, комментатор слишком уж категоричен. Ну и потом, я слабо себе представляю, как можно использовать ORM, без чёткого понимания, что и зачем он генерирует.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

34. Сообщение от Аноним (34), 04-Июл-22, 21:51 +1 +/–

Sql injection в 2022? Достижение!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64

35. Сообщение от Онаним (?), 04-Июл-22, 21:59 +2 +/–

Народ ныне очень любит ORM отрывать от логики объектов, превращая его в прослойку между объектами и БД, и запихивая всю логику обработки полностью в рассредоточенные контроллеры. Вот с этого подхода лично меня коробит, это лишняя абстракция ради абстракции
Сам предпочитаю жирный ORM и контейнеры. Когда объекты из ORM рассованы по своим управляющим контейнерам, отвечающим за вгрузку-выгрузку, и когда они работают как полноценные объекты от логики - представляя собой не только тупой набор данных, но и всё, что нужно для их обработки. Из ORM у этих объектов "лишнего" только чтение-запись-удаление, в остальном они обычная часть логики обработки. Наличие контейнеров позволяет оптимизировать внутри контейнеров такие операции, как нестандартная выборка по условию, добавляя те части SQL, которые в самых дубовых 1-1 ORM'ах реализуются через одно место внешними запросами и впихиванием данных.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от Онаним (?), 04-Июл-22, 22:03 +/–

Пока у тебя да, полтора товара на витрине, как правильно указали - тебе пойдёт и один запрос на объект.
Но когда у тебя хотя бы 100M записей в день начнёт капать, которые ещё надо с другими объектами связывать, тебе так или иначе их придётся пакетной обработкой проходить...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

37. Сообщение от Онаним (?), 04-Июл-22, 22:07 +1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #44

38. Сообщение от Онаним (?), 04-Июл-22, 22:07 +1 +/–

Хотя конечно после cast(key as integer) там уже точно ничего не страшно

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

39. Сообщение от Онаним (?), 04-Июл-22, 22:11 +/–

max([int(k) for k in self.relations]) - это какая-то хитрая чёрная магия?
Или просто у нас все объекты предвгружены? А если их там 100500000 и каждый по килобайту размером?
В жирных специфично сдизайненных контейнерах ORM получится что-то типа self.relations.getMaxByKey('k'), тогда уже да, никакой магии, просто эксплицитная поддержка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #40, #43

40. Сообщение от Онаним (?), 04-Июл-22, 22:13 +/–

Но если к max() надо ещё условие присандалить, то будет получаться шиза вида self.relations.getSubCollection(...conditions).getMaxByKey('k'), и это шиза.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

41. Сообщение от Онаним (?), 04-Июл-22, 22:16 –1 +/–

Поскольку тормозит применительно к питону - это его естественное состояние, всё вами описанное таки верно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

42. Сообщение от Онаним (?), 04-Июл-22, 22:19 +1 +/–

Ды не, ORM своё место. Тут стоит для начала вернуться к тому, что ORM от SQL-injection как правило не спасает, поскольку часть вещей на ORM всё равно нереализуема и сваливается к передаче в ORM кусков запроса. Самый простой пример - когда надо вгрузить объекты, подходящие по длинным цепочкам пропертей других объектов. Нет, можно всё повгружать "по порядочку", но когда у тебя на каждом шаге по миллиону записей - это становится немножко накладно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

43. Сообщение от Аноним (6), 04-Июл-22, 22:45 +/–

Это именно получение последнего по времени объекта из жсона, с ним можно работать как с обычным хеш тейблом. Только возвращает всё текстом, мне не понравился вариант пропатчить на поддержку других типов. При необходимости, он сначала подгружается (целиком, там undefer, да). Изменений там от 0 до нескольких за месяц, содержит категории и ссылки на данные (которые не обязательно имеются в одной из таблиц). Мне показалось это подходящим для моих задач, но я так и не смог нагуглить ничего даже отдалённо похожего. Потом можно будет скидывать старые данные куда-нибудь на диск, это же жсон.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

44. Сообщение от Аноним (6), 04-Июл-22, 22:52 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

45. Сообщение от Без аргументов (?), 05-Июл-22, 00:03 +/–

Ну я же говорю, что это детский садик. Другое дело когда у вас оракл и 120ГБ ОЗУ и пол терабайта данных продаж с тысячи магазинов за пол года перелопатить надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #46

46. Сообщение от Аноним (6), 05-Июл-22, 00:11 +/–

Так если бы там были какие-то данные, я бы как минимум не стал использовать жсон в sqlite. Речь то совсем о другом. Я сомневаюсь, что перелопачивать пол терабайта надо прям на каждый запрос (для такого памяти маловато опять же), а значит, не исключено, что орм тут себя прекраснейшим образом проявит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

47. Сообщение от Аноним (47), 05-Июл-22, 04:32 +1 +/–

Перечисленные методы в нормальных руках (при нормальных мозгах) никогда не будут принимать непроверенные параметры. Расходимся посоны...

Ответить | Правка | Наверх | Cообщить модератору

48. Сообщение от ПерлухаБратуха (?), 05-Июл-22, 04:46 +/–

> тут никаких проблем быть не может.
Вот так и начинаются кадастрофы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #53

49. Сообщение от GG (ok), 05-Июл-22, 10:53 –2 +/–

ОРМ нужен не для того чтобы неадекватную архитектуру покрывать.
Если кто-то модель данных спроектировал так что там без такого геморроя велосипедов запрос не сделать — надо гнать его ссаными тряпками из профессии и переделывать нормально, а не городить вот это вот.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #55

50. Сообщение от GG (ok), 05-Июл-22, 10:56 –1 +/–

> нет двухстороннего маппинга
Давно уже есть, просто довольно нетривиально

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

51. Сообщение от GG (ok), 05-Июл-22, 10:57 –3 +/–

Вон из профессии

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

52. Сообщение от GG (ok), 05-Июл-22, 11:00 –1 +/–

Если у тебя набор данных сложнее товаров для витрины превращается в непроходимую кучу — это исключительно твоя проблема.
И заключается она не в ОРМ, а в том что ты себя возомнил архитектором, когда на самом деле тебе и бейджик кодера-юниора снимать рано ещё.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

53. Сообщение от Аноним (6), 05-Июл-22, 13:44 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

54. Сообщение от Аноним (61), 05-Июл-22, 14:06 +/–

> непроверенные внешние данные
А раст может как-то помочь? Или в расте такие же дыры?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57

55. Сообщение от Аноним (6), 05-Июл-22, 14:39 +/–

Хех, но ведь это же вообще не имеет отношения к ORM, претензия должна быть к SQL (ну или к json).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

56. Сообщение от Аноним (56), 06-Июл-22, 03:13 +1 +/–

На практике в нормализованных БД слишком много джойнов, даже если это база микросервиса с довольно узкой зоной ответственности. Поэтому денормализация до второй формы
и требования к "академичности" пониже и код пожиже. Зато работает в рамках заданного SLA.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #67

57. Сообщение от Аноним (56), 06-Июл-22, 03:25 +/–

От ошибок в бизнес-логике раст тоже не защитит. Только от гонок и некоторых видов утечек в куче.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #58

58. Сообщение от Аноним (6), 06-Июл-22, 03:47 +1 +/–

Пока вебрендера не было, синхронизация вкладок не отваливалась.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #60

60. Сообщение от Аноним (60), 06-Июл-22, 17:45 +1 +/–

Ратс не нужен забудь про него плз.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #65

61. Сообщение от Аноним (61), 06-Июл-22, 19:50 +/–

> всё норм, ничего не бомбит
особенно тут:
> where(text("key and json_type(key) == 'integer' and type=='object'"))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #62

62. Сообщение от Аноним (6), 06-Июл-22, 20:08 +/–

Разве что, чуточку. Но в SQL это выглядело не лучше и позволяло выполнить подстановку чего-нибудь нехорошего в 5 местах, а тут не получится.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #68

63. Сообщение от Аноним (63), 07-Июл-22, 14:41 +/–

В эксплоит. Эксплоит тебе придеться купить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

64. Сообщение от Аноним (63), 07-Июл-22, 14:43 +/–

Достижение, что наконец-то лидерство какого-то говнянеького фреймворка начинает шататься.
Вопрос только, что где что-то можное современное молодежное с асинхроньщиной и поэтессами =)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

65. Сообщение от Аноним (63), 07-Июл-22, 14:49 +/–

Так его так и не доснимали же ...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

66. Сообщение от Аноним (66), 07-Июл-22, 18:38 +/–

>Вы что-то делаете не так.
Да, я, например, хочу строить запросы одинаково на любом рантайме.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

67. Сообщение от Онаним (?), 08-Июл-22, 00:03 +/–

Ха. Да. Дальше второй формы уходить - это уже для особых случаев. Когда не жалко.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

68. Сообщение от Аноним (68), 09-Июл-22, 17:02 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 04-Июл-22, 15:32	+/–
просто используешь построитель запросов и все. Но нет, давайте клеить sql-строку самому.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #4

2. Сообщение от васёк (?), 04-Июл-22, 15:36	–1 +/–
и питоша тоже? я думал только Сишка дырявая
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #3, #5

3. Сообщение от Корец (?), 04-Июл-22, 15:46	+1 +/–
>я думал только Сишка дырявая Не переживай, дырявым может быть код на любом языке. Даже на том самом ;)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

4. Сообщение от Без аргументов (?), 04-Июл-22, 15:50	–6 +/–
Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #6, #7, #9, #11, #17, #26, #42

5. Сообщение от Без аргументов (?), 04-Июл-22, 15:51	+/–
А у тебя минимум 4 дырки.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

6. Сообщение от Аноним (6), 04-Июл-22, 16:06	–7 +/–
У меня конструкции вида select(func.max(text("cast(key as integer)")),text('value')).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'")) всё норм, ничего не бомбит. Легко читается, даже легче, чем чисто sql. Вы что-то делаете не так.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #8, #24, #37, #38, #61, #66

7. Сообщение от Аноним (7), 04-Июл-22, 16:09	+3 +/–
Опять все путают ORM и Query Builder. ORM нужна для того, чтобы автоматически организовать как сохранение данных дерева объектов в РСУБД, так и восстановление их из сохраненных в РСУБД данных в память. Такая своего рода сериализация, только в РСУБД, что позволяет эффективно организовать поиск по данным. Query Builder нужен преимущественно как часть ORM для построения запросов для поиска нужных объектов в базе. При использовании Query Builder совместно с ORM важно, что они друг с другом интергрированы, и в качестве результата будут получены не сырые данные из базы, а нужный объект (или коллекция) со всеми вложенными объектами-коллекциями. Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). Query Builder-ы иногда полезны, если запрос строится в зависимости от данных, запрошенным пользователем - без них довольно неудобно собирать запрос по частям (что-то в select, что-то в join, что-то в where и т.д.). Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy. С более примитивными QB, которые разработаны как вспомогательные части для ORM, будет проще генерировать запрос вручную.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #18, #50

8. Сообщение от Аноним (6), 04-Июл-22, 16:11	–2 +/–
Кстати, там то же самое рядом через ORM, если это зло и намного хуже, то я даже не знаю ем тут помочь. maxvalue = max([int(k) for k in self.relations]) return (maxvalue, self.relations[str(maxvalue)],) а вот это orm-sql return select(func.max(text("cast(key as integer)"))).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'")) ну и где читаемее?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #25, #39

9. Сообщение от kai3341 (ok), 04-Июл-22, 16:16	–3 +/–
> Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо. Меня тоже бомбило, но потом я попробовал алхимию: https://habr.com/ru/post/559738/ Выходит плюс/минус тот же самый синтаксис
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #12

11. Сообщение от Аноним (11), 04-Июл-22, 16:53	+2 +/–
Расскажи пожалуйста подробно, зачем ты делаешь сложные операции? Ты не думал что твои геройствования связаны с плохой архитектурой?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #20, #27, #36

12. Сообщение от Аноним (12), 04-Июл-22, 17:30	+/–
Если выходит плюс минус так же, зачем? Чтобы что? В базу оно все равно пойдет в виде запроса. Лишь бы не писать SQL? Из той же серии билдеры регулярных выражений (не путать с грамматиками). Иррациональный страх перед технологиями отцов-основателей? Своё лучше пахнет и делает волосы мягче и шелковистее?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #13

13. Сообщение от kai3341 (ok), 04-Июл-22, 18:19	–2 +/–
Как думаете, зачем я дал ссылку на статью? Ответ -- в ней ответы на заданные вами вопросы и некоторые ещё не заданные
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

14. Сообщение от Аристарх (??), 04-Июл-22, 18:46	–2 +/–
> подстановку своего SQL-кода Тест на имбецила в 21 веке. Если такая ошибка находится, СРАЗУ же в отдел кадров на увольнение по собственному!
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #22

15. Сообщение от Sergey (??), 04-Июл-22, 18:46	+/–
А как это можно использовать ? Не совсем понятно, куда нужно вбивать свой СКУЛь запрос ;(
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #63

16. Сообщение от Аноним (17), 04-Июл-22, 18:49	+1 +/–
Нужно использовать "подготовленные выражения" и тогда sql-иньекции станут невозможны.
Ответить \| Правка \| Наверх \| Cообщить модератору

17. Сообщение от Аноним (17), 04-Июл-22, 18:56	+/–
А каким образом Вы боретесь с уязвимостями типа "sql-иньекция"?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #21

18. Сообщение от kai3341 (ok), 04-Июл-22, 19:29	+/–
> Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). > Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy Вот весь прикол в том, что аналитические запросы есть смысл класть на нормальную ORM типа алхимии (DjangoORM говно). Так как статью (ниже) читать дело не царское, скажу тут. ORM позволяет сделать SQL-запрос модульным, позволяет повторно переиспользовать код через наследование или композицию. Также адекватная ORM умеет в вывод типов. Алхимия позволяет также реализовывать макросы, что удачно сочетается с выводом типов. Ещё раз для тех, что не умеет читать: чмORM типа той же djangoORM дают преимущества только на простейших запросах (CRUD), но на аналитике дрыщут в лужу. Адекватные ORM типа алхимии дают как преимущества на банальном CRUD, так и на аналитике. Ну и таки шо по производительности? Если верхний мозг не использовать, то алхимия тормозит, джанга чуть меньше тормозит. Если верхний мозг в наличии, то небольшие тормоза получаем на этапе инициализации, но в рантайме производительность мало отличается от raw sql. Вопросу уделено особое внимание в статье А ещё про миграции никто не рассказал
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #19, #41

19. Сообщение от Аноним (19), 04-Июл-22, 19:41	+/–
Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам нет, не совсем корректно называть это ORM.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #23

20. Сообщение от Без аргументов (?), 04-Июл-22, 19:45	+/–
Я работал разработчиком BI-отчетов и витрин данных. Там на первом месте оптимизация и скорость выполнения. Как выше написали, ORM/QB детский садик работает для примитивных CRUD. Насчет мапинга не скажу, что удобнее. Точнее мапинг можно и из сырого запроса сделать без всякого блоатваре.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #51

21. Сообщение от Без аргументов (?), 04-Июл-22, 19:46	+/–
Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще изкоробки обычно есть постановка параметров (через ???), которая проверяет.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #28

22. Сообщение от Без аргументов (?), 04-Июл-22, 19:47	+1 +/–
Соглы.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14

23. Сообщение от kai3341 (ok), 04-Июл-22, 19:48	+/–
> Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую > гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам > нет, не совсем корректно называть это ORM. Пользуясь случаем, о каком двустороннем маппинге речь? Об ActiveRecord? Если да, то где он вообще есть для такого типа запросов?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19

24. Сообщение от Без аргументов (?), 04-Июл-22, 19:52	+/–
Я ничего тут не понял что там у вас про JSON. Я говорю про человеческую нормализованную СУБД. Но сразу виду обезьянокод. Какие-то двойные преобразования типов из текста в число. И еще макс можно сделать в одном запросе без вложения.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #30, #56

25. Сообщение от Без аргументов (?), 04-Июл-22, 19:54	+/–
везде нифига не понятно. интересно, как это будет работать, если строк миллион. а можно ли передать ему подсказку, в каких случаях использовать и какие индексы? нет.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #31

26. Сообщение от Без аргументов (?), 04-Июл-22, 19:56	–1 +/–
Нифига сколько неосиляторов в SQL минусонуло. Ну я тоже с трудом въезжал. Пока не научился делать пятэтажные запросы и такие, и сякие, с динамической группировкой и фильтрами на тысячу строк кода. А бывает, когда в СУБД надо передать хинты, т.к. оптимизатор не экстрасенс на все случаи жизни
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #33

27. Сообщение от Без аргументов (?), 04-Июл-22, 19:57	–1 +/–
Вся эта шелуха работает до тех пор, пока проект более менее не вырастет в большую кучу данных, а не тупо выбрать товары, чтобы в вебне показать витрину.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #32, #52

28. Сообщение от kai3341 (ok), 04-Июл-22, 20:05	+/–
> Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще > изкоробки обычно есть постановка параметров (через ???), которая проверяет. Любой драйвер БД умеет в подстановку значений. Я рекомендую читать документацию
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21

29. Сообщение от Онаним (?), 04-Июл-22, 20:10	–1 +/–
затонеphp(tm) Суть та же, криворучки - они повсюду.
Ответить \| Правка \| Наверх \| Cообщить модератору

30. Сообщение от Аноним (6), 04-Июл-22, 20:16	+/–
Да не, тут нормально всё. Это json в sqlite, надо получить последнюю по времени запись из поля с жсоном, ключи в котором принудительно конвертируются в текст, а значит, последнее значение из текстового ключа не получить. Я это к тому, что даже если ORM не позволяет решить не стандартную задачу адекватно (вставки text), это всё ещё вполне прилично выглядит в результате, куда лучше чем голый зубодробительный sql с сотней уязвимостей на запрос.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #45, #49

31. Сообщение от Аноним (6), 04-Июл-22, 20:19	+/–
Прекрасно это работает. Откуда там миллиону взяться, если поле с жсоном обновляется пару раз в месяц? Причём, используется всегда только последнее значение, старые данные остаются для истории. Тут никаких проблем быть не может.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #25 Ответы: #48