Выше написал комментарий, что создатели Propel2 таки считают, что «защита от дурака» — задача фреймворка. https://habrahabr.ru/post/305432/#comment_9745876
Заглянул в исходники Propel2. Нашел такой блок https://monosnap.com/file/YJxmtXGp7qEiF3k4VXV4rjTKe9bTKC
ModelQuery::create()->delete(); не сделаешь уже. По крайней мере в случае человека выше (https://habrahabr.ru/post/305432/#comment_9696300) защитило бы.
>> Ну вот сидит какой-нибудь админ в каком-нибудь датацентре и целыми днями копается в данных пользователей
А что сейчас ему это мешает делать? Это как было незаконным, так и остается.
>> Гигабайты трафика в секунду будут улетать в мафию, доны Корлеоне наймут ИТ-шников для выискивания поводов для шантажа каждого второго, нет, каждого первого
Фантазии, к сожалению, нельзя ни доказать, ни опровергнуть
>> Странный вы человек. Приходило когда-нибудь в голову, что люди не хотят, чтобы в их трафике шарились все, кому не лень, просто потому что не хотят этого?
Где вы в законе увидели положения, согласно которым в вашем трафике могут «шариться все, кому не лень»?
По такой логике шаблонизатор с автоэкранированием — защита от дурака. А что, забыл экранировать на выводе — твои проблемы.
Фреймворки и библиотеки должны по возможности защищать от типичных ошибок. DELETE и UPDATE без WHERE блока в 99% случаев — ошибочная ситуация. Ну на крайняк WARNING кидать неплохо бы.
Справедливости ради случай с удалением всех строк из таблицы фреймворки действительно могли бы и обрабатывать. Т.е. при генерировании запроса DELETE FROM table_name из querybuilder-a кидать исключение, а если нужно действительно удалить все строки, то завести для этих целей отдельный метод truncate().
>> Для разделения экранов достаточно пакетов. Зачем плодить миллион модулей?
Чтобы нельзя было шлепнуть import того, чего не должно быть. Модульный подход заставляет писать менее связный код.
>> Что, по идее, должно замедлить сборку, к тому же.
Совершенно необязательно. Под каждый модуль можно с помощью flavor тонко настроить dev-окружение, когда компилится только сам модуль и его зависимости. В итоге сборка даже быстрее для дева.
Зачем же 1 к 1. Группируйте экраны по назначению. Экран списка статей и экран самой статьи, например, близки по назначению и можно оформить в отдельный модуль.
>> Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.
Совершенно разные по назначению экраны при правильной архитектуре не должны иметь кольцевых зависимостей.
>> Потому что современные интернет магазины не кешируют ничего даже для анонимов/гостей. Необходим анализ переходов пользователя для отображения спец предложений, похожих или возможно заинтересующих товаров. Маркетологи на крупных проектах сейчас пытаются каждые вероятные 0,5 процента выжать.
ModelQuery::create()->delete(); не сделаешь уже. По крайней мере в случае человека выше (https://habrahabr.ru/post/305432/#comment_9696300) защитило бы.
А что сейчас ему это мешает делать? Это как было незаконным, так и остается.
>> Гигабайты трафика в секунду будут улетать в мафию, доны Корлеоне наймут ИТ-шников для выискивания поводов для шантажа каждого второго, нет, каждого первого
Фантазии, к сожалению, нельзя ни доказать, ни опровергнуть
UPDATED. Или это сарказм был? =)
Где вы в законе увидели положения, согласно которым в вашем трафике могут «шариться все, кому не лень»?
Нет, просто «Нет WHERE блока — исключительная ситуация».
Фреймворки и библиотеки должны по возможности защищать от типичных ошибок. DELETE и UPDATE без WHERE блока в 99% случаев — ошибочная ситуация. Ну на крайняк WARNING кидать неплохо бы.
Чтобы нельзя было шлепнуть import того, чего не должно быть. Модульный подход заставляет писать менее связный код.
>> Что, по идее, должно замедлить сборку, к тому же.
Совершенно необязательно. Под каждый модуль можно с помощью flavor тонко настроить dev-окружение, когда компилится только сам модуль и его зависимости. В итоге сборка даже быстрее для дева.
>> Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.
Совершенно разные по назначению экраны при правильной архитектуре не должны иметь кольцевых зависимостей.
Так сразу в /dev/null, чего мелочиться :)
Когда начинал только программировать на ruby, при встрече в чужом коде с unless мой «парсер кода» начинал жутко тормозить и уходить в свап.
Это все можно на джаваскрипте асинхронно сделать.
Очень оптимистичные оценки. Еще на 2 порядка ниже.