FishHook
Я не тупо скопировал решение со стековерфлау, я в нем разбирался. Я не понял немного 1 момент конечно, нов целом, что делает код понимаю.
Джанго мне не нравится, в этом я понимаю 4kpt. В детали не буду вдаваться, потому что это будет просто открытие “священных войн”, а мне это не надо.
Полная версия: SQLAlchemy class сериализовать в json
Джанго говно. Аллелуйя 
Автоматический сборщик json это, конечно, хорошо, но, зачастую в моделях не нужны все поля или часть из них должна каким-то образом предварительно обрабатываться. Внутри модели прописывается метод to_json, который проводит сериализацию в нужный Вам объект. Чаще всего “автоматически” не значит хорошо. Но это мой опыт, он может быть неверным или ошибочным. Мы ломали уже копья на автоматическом варианте… Наш механизм еще парсил все связи на нужную глубину и сериализировал также полученные объекты. Но в этом случае могут быть проблемы и серьезные. Поэтому лучше трижды подумать. А надо ли оно Вам
Я для сериализации пользуюсь вот этой библиотекой https://marshmallow-sqlalchemy.readthedocs.io/en/latest/ Есть еще eve-sqlalchemy, но она идет уже с фласком. Еще можно попробовать поменять значение “dynamic” на дефолтное “select” у параметра lazy.
Кстати этот параметр lazy, то еще “креативное” решение у sqlalchemy. Он принимает за каким-то чертом 8 значений и каждое из них несет свой функционал. Например, если я ставлю select, то я не смогу фильтрануть поле, например parent.children.filter(…) - так не получится. Если же я ставлю “dynamic”, то не могу использовать joineload для запроса и получаю проблему n+1 запроса для определенных вью. Быть может если покопаться, то можно найти какой-нибудь superlazyload и использовать его вместо joinedload, но я забил на это дело, да и не факт, что с этим параметром не отвалиться что-нибудь другое) Это я к вопросу об убожестве Django ORM, в котором всё прекрасно и универсально работает без всяких параметров для relation полей.
Кстати этот параметр lazy, то еще “креативное” решение у sqlalchemy. Он принимает за каким-то чертом 8 значений и каждое из них несет свой функционал. Например, если я ставлю select, то я не смогу фильтрануть поле, например parent.children.filter(…) - так не получится. Если же я ставлю “dynamic”, то не могу использовать joineload для запроса и получаю проблему n+1 запроса для определенных вью. Быть может если покопаться, то можно найти какой-нибудь superlazyload и использовать его вместо joinedload, но я забил на это дело, да и не факт, что с этим параметром не отвалиться что-нибудь другое) Это я к вопросу об убожестве Django ORM, в котором всё прекрасно и универсально работает без всяких параметров для relation полей.
plusplusОчевидно же
Если же я ставлю “dynamic”, то не могу использовать joineload для запроса и получаю проблему n+1 запроса для определенных вью
plusplus
Это я к вопросу об убожестве Django ORM, в котором всё прекрасно и универсально работает без всяких параметров для relation полей.
Нужна конфигурация под определенную задачу. “Серебряной пули” в алхимии не существует. И существовать не может. Это плата за возможность мощной кастомизации…
4kpt_IVДля меня очевидно, что в джанге такой очевидности, слава богу, нет.
Очевидно же
4kpt_IV
Нужна конфигурация под определенную задачу. “Серебряной пули” в алхимии не существует. И существовать не может. Это плата за возможность мощной кастомизации…
А если конкретно, какая конфигурация нужна? Я думаю даже пример приводить не надо, настолько частый кейс, когда relation поле и фильтровать надо и joinedload-ить. Как быть? Создавать два поля, одно select, другое dynamic? Или сразу все 8?)
plusplus
Для меня очевидно, что в джанге такой очевидности, слава богу, нет.
Для меня очевидно, что Вам нужно на джангу…
plusplus
Или сразу все 8?)
Создавайте сразу 28. Моя Вам рекомендация