>> Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по
>> 4к, ибо это ненормально.
> Так у тебя они будут - ты же собрался всю историю в
> запросе держать.Какую историю? Всё состояние. Обычный dict. Для корзинки магазина это список товаров (как минимум, для копирования). Если строка будет большой, значит, нельзя будет скопировать. Обидно. Но я в пыхерских проектах видел столько "нельзя" на ровном месте, что по сравнению с этим желание перекопировать весь магазин - это мелочи.
Но на текущий момент я не вижу причин отказываться от простого решения из-за заведомо неправильного действия.
> Вот о том и речь - что лучше СРАЗУ выбрать другие средства. Инженерно оправданные.
Не знаю, как в ваших системах, а когда навешиваешь на before_hook контекстный локал, ему без разницы, откуда брать данные, и поэтому изменение источника получения - это одна строчка, которая сразу же скажется на всей программе. Нахрена выбирать заведомо более тяжёлое средство, особенно на этапе разработки, усложняя себе жизнь, когда это вообще не проблема? Планирование обычно помогает избегать проблем, а когда в лоб решаешь, всё усложняя и усложняя, потому что "а какие могут быть крайние случаи? сколько нужно резерву?" - привет, проблемы. Причём, усложнение - это и путь реальных ошибок, которые могут что-то серьёзное сотворить. А не запланированных ограничений, которые предсказуемы и могут быть оформлены в правила.
> А не писать "концептуальную" вещь, которую через месяц надо будет выкинуть, ибо
> заложенные красивые концепты оказались полностью несовместимы с реальностью.
Пока это пыхеры свои мега-убер проекты всё время с нуля переписывают.
> Который как раз и обрежет тебе запрос теми самыми 4-16К.
Пусть режет. Если это запланированное поведение.
