Мы ORM - можем маппировать и в POJO, и в классические kotlin классы. Но прижившееся использование мапы. Именно в силу того, что не требуется генерация лишних слоёв классов.
JOOQ - это "database first". Мы именно не хотели копировать (делать похожим) синтаксис SQL. Также в качестве источников мы можем использовать не только SQL базы, но и всевозможные REST, GRPC и т.п. Мы используем CTE (common table expression) в рекурсивных запросах.
В 2018 году, когда мы начинали и исследовали, что уже есть, Exposed был в полузачаточном состоянии. И мы скорее были близки к выбору проекта graphql-over-sql в качестве основы. В конечном счете выбор пал всё же на собственный DSL запросов (graphql-like). На данный момент мы развиваемся в сторону федеративных запросов (комбинатор), собирая и комбинируя данные из разных источников, что, видимо, не может Exposed.
С одной стороны - мы не претендуем на бессмертие, а с другой - разве нельзя считать эту статью первым шагом?
И, безусловно, интерес о смерти фреймворка будет очень интересен.
Мы ORM - можем маппировать и в POJO, и в классические kotlin классы. Но прижившееся использование мапы.
Именно в силу того, что не требуется генерация лишних слоёв классов.
Фреймворк уже используется в нескольких федеральных и региональных государственных системах. Корзина не грозит.
JOOQ - это "database first". Мы именно не хотели копировать (делать похожим) синтаксис SQL. Также в качестве источников мы можем использовать не только SQL базы, но и всевозможные REST, GRPC и т.п.
Мы используем CTE (common table expression) в рекурсивных запросах.
В 2018 году, когда мы начинали и исследовали, что уже есть, Exposed был в полузачаточном состоянии. И мы скорее были близки к выбору проекта graphql-over-sql в качестве основы.
В конечном счете выбор пал всё же на собственный DSL запросов (graphql-like).
На данный момент мы развиваемся в сторону федеративных запросов (комбинатор), собирая и комбинируя данные из разных источников, что, видимо, не может Exposed.