Https://Dpaste.Org/8HXw0 Прошу обоссать меня всем желающим. Как можно улучшить этот код? Нужно ли

вообще? Структура сильно менятся не будет - бд по задумке разрастаться не будет. Некуда и незачем.

обычно не стоит форматировать SQL через .format()/f-строки во избежание SQL-инъекций

целочисленные айдишники это прошлый век, бери ууиды/object id

Это сарказм?

Можно, если прогнать через протект метод переменную во время вставки или сразу

нет, why?

ну, автоинкриментный целочисленный айди как-то привычнее. Uuid нужны в распределенных системах.

привычнее-то он привычнее, но у него много минусов: — айдишники разных сущностей пересекаются, из-за этого много возможностей набаговать, в том числе написать некорректные тесты — можно извне следить за бизнес-показателями сервиса, следя за ростом айдишников

У Uuid минусов не меньше. Вопрос лишь в том, какие из минусов критичнее для конкретного проекта.

можно список?

С телефона лень писать портянку, но вполне адекватных статей со сравнениями полон интернет.

Требуется их генерировать, коллизии, индекс тяжелее

Даже если говорить про v7?

Размер, производительность, человекочитаемость

ну второе да. Это правда, но при условии что клиент видит твои айдишники. В случае например телеграм-бота он такую информацию не получит, если ты только сам не сообщишь. В заметной степени проблему можно решить использованием slug-ов. По поводу первого все-таки спорно. Современные подходы программной архитектуры позволяют достаточно абстрактно работать с сущностями даже полагаясь на чистый sql. Фактически если посмотреть монографии Мартина Фаулера и Эрика Эванса, то там паттерны часто показаны с использованием чистого sql которые авторы показывают как абстрагировать.

У любых, в общем-то. Банально некоторые плюсы в другой ситуации становятся минусами и наоборот.

генерировать — почему это проблема? весь код уже написан. коллизии это проблема на уровне коллизий в гите. никто никогда с коллизией не столкнётся. а производительность — это минорная проблема по сравнению с потенциальными багами и утечками, не так сильно она страдает, чтобы это рассматривать всерьёз (на масштабах, где нужно — всё равно система уже распределённая и по-другому никак)

ну человекочитаемость это как раз один из минусов

Коллизии? O_o

про монографии интересное замечание. кто читает монографии и пишет код по ним?) на деле в той же джанге в фильтре id взять не из той сущности — совершенно повседневный косяк, а в тесте не отловишь, потому что всех сущностей по одной и у них у всех id = 1.

Можно креативнее подходить к id в тестах. У нас иногда рандомизировались, например. Да и кроме id у сущностей есть куча других элементов. Как их спутать?

Да я не против, сам их постоянно юзаю, удобно когда надо интегрировать разные сервисы у которых разные бд

ну это надо про рандомизацию ещё вспомнить) другие элементы не надо путать чтобы набаговать. вот у тебя есть в коде lesson и course, и ты пишешь Student.objects.filter(group__course_id=lesson.id) и всё, у тебя баг

А тебе что помешает с тем же успехом один и тот же uuid в тесты подставлять? ;⁠-⁠)

Обидное замечание. Ну я стараюсь реализовывать то что прочитал. Вот то что человек выше запостил с просьбой "обоссать" это отчасти результат моих рекомендаций. Или вот еще сегодня было обсуждение https://t.me/ru_python/2068947. Много обсуждения современной программной архитектуры у нас проходит в @fastapi_ru. Де-факто это кружок обсуждения Чистой Архитектуры и DDD. Так что ну кто-то пишет по книжкам.

ну это нудно

Ну а как ты будешь их иначе задавать, чтобы тот же подход был не применим к обычным автоинкрементным?

i meant no offence, конечно, есть люди, которые пишут по книжкам, но ты этого не можешь от всех ожидать. у тебя есть сложные меры защиты от багов (архитектура то-сё) и простые (использовать везде uuid вместо численных — можно даже линтером заэнфорсить), зачем отказываться от простых

ну вот когда у тебя uuid, они все неизбежно рандомизированные, так что думать не надо и забыть рандомизировать нельзя

В тестах данные из каких-нибудь фикстур подгружаются обычно. Шут его знает, что туда накопипащено.

Ещё можно нечаянно сделать так, что можно перебрать ресурсы по порядку. На одном сайте недавно нашёл такое. Суть: можно заплатить небольшую сумму и смотреть подробную статистику по своей <штуке>. Но можно немного поменять ID в адресной строке, и увидишь статистику по чужой <штуке>, которую видеть вообще не следует

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

Моках это mocha hardhat? Или вы про другое?

Я про заглушки

А

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

звучит как троллинг. Если я пишу на скулайт - смогу ли я нормально заюзать UUID и не напортачить, тем более на "проде"

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

То есть то что оно трещит по швам на ровном месте - тебя не смущает?

где именно? Для этого и скинул ПыСы Представим, что ОРМ не существует. Не умею я в них.

Отвечали же. Первая кавычка в данных - всё осыпалось.

Забей,это же не крупное😂

А как...

Красиво и с фейерверками. Нефиг так запросы собирать. Ну и структурно - треш какой-то.

а. А блять. Я-то думаю - хули не так. Всё, я понял. Почему-то не допер с самого начала, что это говнище, в строку валюэ вставлять.

уууух

Да. Я только допер. Да.

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

я бы предложил выкинуть кодогенерацию

кодогенератора*

а как ещё можно решить проблему динамического поиска по параметрам? (когда не все параметры указываются) Разве не логично формировать скулайт запрос в зависимости от входящих параметров поиска?

where (column1 = parameter1 or parameter1 is unspecified) and (column2 = parameter2 or parameter2 is unspecified)`

Таааакс. Можно ссылку на доки? Я не понимаю что это. Хотя че туплю. Сам найду

доки на AND и OR в sql?

is unspecified

is unspecified это псевдокот, в реальности будет is null или = 0 или cardinality(parameter) = 0 или т.д.