m-kicherov, посколько это - Sanic - это web-фреймворк то все усилия надо направить на простой способ отдачи кода ошибки клиенту.
С точки зрения http-клиента никаких исключений не бывает. Бывают коды состояний HTTP. Например 400-тки. Они говорят что с клиента на сервер прилетела фигня. Например формат реквеста некорреткный. И в тексте идет пояснение.
Или 500-тки. Они говорят что на сервере случилась фигня. Например закончилась память.
Вобщем автор ты можешь придумывать самые невообразимо красивые pythonic-ways но в конечном счете контейнер этого Sanic завернет твою логику в простую HTTP-ошибку. Какую - я не знаю надо читать документацию.
Вобщем подумай в этом направлении чтоб не делать ненужную работу.
Алексей Черемисин, да. Обычно ORM - это когда сложная доменная модель и класс транзакций OLTP.
Тоесть коротенькие точечные транзакции. Взяли объектик. В формочку. Юзер поправил.
Сохранили.
А если выборки выбирают много данных (datarows) - то это DWH/OLAP/Bigdata. Там никакого ORM нельзя.
И не дай бох грузить в коллекции. Никакой памяти Java не хватит. Счет идет начиная от миллионов обычно.
Там - SQL и специальные диалекты навроде Spark/Hive e.t.c. Аналитика. Отчеты.
Виктор, я не против. Пускай автор гуглит терминологию. Может он выйдет на другой софт или железо которое это делает. Эквалайзеры с пре-сетами были раньше во всех модных звуковушках. В CreativeLabs были. Но у автора - такой случай который очень сильно подходит под тон-компенсацию. Других смыслов крутить тембр обычно нет.
Это может быть не связано с заменой материнки. Попробуй найди ноутбук и смоделируй на этой-же игре этот скрин с цифрами. Я думаю что просто сеть периодически штормит и там идут такие процессы. Тем более что ты говоришь что процесс - периодический.
Мне просто вспоминается опыт миграции кода после Java-8 когда все пересели на lambda-expressions. Много кода было переписано в соотвествии с feature. Код стал визуально компактнее. Потом пошли проблемы. Стектрейс стал нечитаем. Обработка исключений стала сложнее. Переменные сложнее втащить из внешнего скоупа в тело lambda. И мы поняли что просто обменяли шило на мыло. Простой for/while loop лучше оптимизируется чем lambda foreach.
Эти все null-safe navigation - хорошая штука. Но логика которая скрыта под капотом (hidden-flow) иногда стреляет. В некоторых новых языках (ZigLang) на уровне манифеста разработчики отказались от любых скрытых flow. Вот они решили что им так легче жить.
Непонятно что ты хочешь сделать. Теоремы не реализовывают а доказывают. И доказывают их
по другому. С языками доказательного свойства. Всякие там ... Prolog, Idris и прочие.
WbICHA, как будет угодно. Попробуйте отстоять вашу точку зрения - когда в коде будут проблемы.
И не в этом синтетическом а в настоящем.
Еще подумайте о том как у вас будут выглядеть code-coverage report. Если coverage вообще применим к JavaScript я тут не в курсе. Но покрытие - это важная вещь и покрыта ли строка зеленым или желтым - важный поинт.
WbICHA, это был простой пример. Представте что там эта цепочка вопросиков до 5 уровней. Она - не выполняется. Почему? На каком уровне вложенности мы выскочили? Надо шаманить с калькулятором выражений.
Короче это вкусовщина. Делайте как вам удобно. Борьба за краткостью кода хороша. Но где-то дальше - игроки вашей команды начнут чесать репу и спрашивать - действительно ли нам нужен такой экстремизм в выражениях. Так мождо дойти до APL и брейнфака.
Иван Мельников, у вас - очень специфичная задача. Сомнительно что кто-то будет базируясь на quality делать стандарты. Тоже самое что практически никто не стандартизировал CRM, ERP и прочее. Ну я не видел ни разу чтоб схема следовала какому-то стандарту.
Делайте своё. Вы его лучше соптимизируете. Даже допустим там будет key-value, где value - JSON документ - то все равно будет хорошо.
