Комментарии 19
Увидел много "потому что котлин" кода. Увидел билдер кверей, радикально отлтичающихся от привычного SQL. Не увидел, в чем преимущество по сравнению с JOOQ, который куда менее многословен и не ломает привычные паттерны работы с SQL.
Ну таки-да, это не ОРМ. ОРМ решает в первую голову задачу объектного мапинга (да даже банально называется Объектно-Реляционным Маппингом) и только по желанию инкапсуляцию SQL-диалектов в свой DSL. Это DSL over SQL. То есть специфический тулинг, как я понимаю, для задач автора. Например, навскидку, шаблонизированного стейт-менеджмента для выборки/солоедита из набора полей/формы замапленной на филдсет.
К сожалению, судьба собственного фреймворка в корзине. Я видел много подобных ситуации. А так ....симпатичный велосипед
Фреймворк уже используется в нескольких федеральных и региональных государственных системах. Корзина не грозит.
ну .... если Вы впихнули свой велосипед в пару проектов, то не значит что обеспечили своему детищу бессмертие. Посмотрите на EclipseLink и Apache OpenJPA. Если бы Вы написали книгу о своем фреймворке, выспутили на паре конференций, написали бы org.springframework.boot:spring-boot-starter-data-datamaps, выпустили бы пару статей типа datamaps vs hibernate ... вот это бы дало шанс на бессмертие. а так .... я Вам даже могу рассказать как будет умирать ваш фреймворк.
С одной стороны - мы не претендуем на бессмертие, а с другой - разве нельзя считать эту статью первым шагом?
И, безусловно, интерес о смерти фреймворка будет очень интересен.
не обижайтесь. я не пытаюсь принижать вашу разработку и что-то в этом роде. Развивайтесь .... у вас серьезные конкуренты в лице JPA, Hibernate, etc.
а последовательность умирания следующая:
1) у разработчика на проекте возникает мысль "зачем мне фреймворк, который я могу только тут использовать?"
2) разработчик, читающий описание вакансии на ваш проект", думает " Что за datamaps? он мне нужен?"
3) архитектор на заседании архитектурного комитета говорит " Hibernate развился очень сильно и делает то, что нам нужно, лучше чем наш фреймворк. Нужно мигрировать."
Пункт N1 говорит о том, что разработчики начинают валить с проекта. Пункт N2 говорит о том, что новые разработчики не горят желанием участвовать в проекте. Пункт N3 - достали лопату для закапывания.
И статус проекта тут вообще ни при чем.
В общем .... удачи вам в вашем начинании!
Мне кажется, здесь не идёт речь (пока) про "переходите все на наш фреймворк". Хотя бы просто потому, что его нигде нет чтобы пощупать. Это скорее демонстрация идей нового ORM для kotlin'а.
Ну а что до велосипедов - большинство продуктов, которые используют разработчики когда-то были велосипедами) Уточненю - под "велосипедом" я здесь подразумеваю не просто копирование существующего продукта, только с худшим функицоналом, а изобретение чего то нового, базирующегося на старых идеях. Во-всяком случае, так выглядит этот фреймворк.
Это решение, в сравнении с тем же Hibernate, выглядит лучше для небольших проектов, где особо нет сложных запросов. Но, на мой взгляд, JOOQ всегда будет выигрывать у тех платформ, которые, в качестве последней надежды, предоставляют возможность писать нативный запрос, т.к. в таком случае кратно увеличивается вероятность допустить ошибку. Ну и само собой, навряд ли получиться обеспечить такую же гибкость, которую даёт JOOQ.
Еще интересно, есть ли у вашей ORM возможность использования CTE?
Похоже вы изобрели Exposed
В 2018 году, когда мы начинали и исследовали, что уже есть, Exposed был в полузачаточном состоянии. И мы скорее были близки к выбору проекта graphql-over-sql в качестве основы.
В конечном счете выбор пал всё же на собственный DSL запросов (graphql-like).
На данный момент мы развиваемся в сторону федеративных запросов (комбинатор), собирая и комбинируя данные из разных источников, что, видимо, не может Exposed.
по-моему этот фреймворк тоже не далеко пойдет .... много писанины по сравнению с JPA.
В прследнее время я пользуюсь to_jsonb и jsob_build_object с последующей сериализации через jackson.
Это устраняет вопрос маппинга как таковой, мы получаем привычный нам jsonчик включающий все нужные поля, в т.ч. массивы с нужными условиями выборки, без танцев с бубном
DataMaps. Рассказ о нашей ORM на Kotlin