Да, соглашусь, выглядит это не особо красиво. Для большей абстракции можно опробовать убрать LazyLoadType и VECTOR_SORT заменить на просто SEARCH. Благодаря Query Builder, бизнес логика может максимально удобно получать нужные данные, посредством одного метода репозитория. Если использовать sqlalchemy orm, то каждый метод будет узко специализирован под конкретный запрос, также может быть и такое, что метод репозитория будет вызван только один раз в каком то месте бизнес логики. Как раз таки под сложными запросами я и подразумеваю те, которые в бизнес логике используются один раз. Вместо создания множества лишних методов, которые также нужно описывать в интерфейсе, можно передать в метод репозитория конфиги, которые потом обработает Query Builder и сформирует из них sqlalchemy запрос. В моём решении могут быть проблемы, но я пытаюсь преподнести именно идею, необязательно всё делать так, как описал я.
ORM Query Builder идёт в качестве надстройки, чтобы обрабатывать конфиги и возвращать готовый sqlalchemy запрос. Если я правильно понял выражение "На уровне Select", то нет, остаться нельзя, потому что тогда в одном методе, где будет создаваться этот select запрос, придётся писать довольно много строк кода для обработки конфигов, здесь можете посмотреть как именно вызываются методы SQLAlchemyQueryBuilder из метода репозитория.
Можете пожалуйста уточнить, где именно детали реализации просочились за пределы репозитория? По поводу Mongo могу сказать, что ещё не пробовал масштабировать на неё, но всё по такому же принципу как и в SQLAlchemy, придумать отдельный Query Builder. Для Redis я создаю отдельный от репозитория интерфейс Cache.
Если я правильно понял, то вы говорите о построении sqlalchemy запроса руками в методе репозитория. При написании проекта я столкнулся с тем, что каждый метод содержит sqlalchemy запрос только под одну конкретную задачу и соответственно их приходится постоянно плодить. Моё решение просто сокращает эти методы, позволяя гибко получать данные из одного метода, ORM Query Builder это по сути надстройка над sqlalchemy orm. Если я всё ещё не ответил на ваш вопрос, то дайте чуть больше информации. ORM Query Builder это по сути небольшая надстройка над sqlalchemy orm
ORM Query Builder составляет запросы при помощи sqlalchemy orm, метод build генерирует этот запрос. ORM Query Builder конфиги преобразовывает в sqlalchemy запрос.
Да, соглашусь, выглядит это не особо красиво. Для большей абстракции можно опробовать убрать LazyLoadType и VECTOR_SORT заменить на просто SEARCH. Благодаря Query Builder, бизнес логика может максимально удобно получать нужные данные, посредством одного метода репозитория. Если использовать sqlalchemy orm, то каждый метод будет узко специализирован под конкретный запрос, также может быть и такое, что метод репозитория будет вызван только один раз в каком то месте бизнес логики. Как раз таки под сложными запросами я и подразумеваю те, которые в бизнес логике используются один раз. Вместо создания множества лишних методов, которые также нужно описывать в интерфейсе, можно передать в метод репозитория конфиги, которые потом обработает Query Builder и сформирует из них sqlalchemy запрос. В моём решении могут быть проблемы, но я пытаюсь преподнести именно идею, необязательно всё делать так, как описал я.
ORM Query Builder идёт в качестве надстройки, чтобы обрабатывать конфиги и возвращать готовый sqlalchemy запрос. Если я правильно понял выражение "На уровне Select", то нет, остаться нельзя, потому что тогда в одном методе, где будет создаваться этот select запрос, придётся писать довольно много строк кода для обработки конфигов, здесь можете посмотреть как именно вызываются методы SQLAlchemyQueryBuilder из метода репозитория.
Можете пожалуйста уточнить, где именно детали реализации просочились за пределы репозитория? По поводу Mongo могу сказать, что ещё не пробовал масштабировать на неё, но всё по такому же принципу как и в SQLAlchemy, придумать отдельный Query Builder. Для Redis я создаю отдельный от репозитория интерфейс Cache.
Если я правильно понял, то вы говорите о построении sqlalchemy запроса руками в методе репозитория. При написании проекта я столкнулся с тем, что каждый метод содержит sqlalchemy запрос только под одну конкретную задачу и соответственно их приходится постоянно плодить. Моё решение просто сокращает эти методы, позволяя гибко получать данные из одного метода, ORM Query Builder это по сути надстройка над sqlalchemy orm. Если я всё ещё не ответил на ваш вопрос, то дайте чуть больше информации. ORM Query Builder это по сути небольшая надстройка над sqlalchemy orm
ORM Query Builder составляет запросы при помощи sqlalchemy orm, метод build генерирует этот запрос. ORM Query Builder конфиги преобразовывает в sqlalchemy запрос.