Comments 8
Извините, но я так и не увидел преимуществ, какая-то надстройка подобия .NET Dapper + миграции. К черту автоматические миграции. Возможно вы не смогли полностью расскрыть идею, спасибо что хоть Database First, но опять же при чем ту ваши миграции?
Если вы отдаляете пользователя от SQL — библиотека в проигрыше и будет забыта и заменена чистым SQL, в обход вашей чудной логике. Тут же посылаются к черту ваши тесты над InMemory Database и человек не понимает зачем вообще взялся за это.
Какие-то аггрегации на клиентской части, для меня это вообще дико. О переиспользовании запросов вообще нет речи. Концепция курсоров для меня не расскрыта, что они делают? Тягают данные на клиент???
Если вы отдаляете пользователя от SQL — библиотека в проигрыше и будет забыта и заменена чистым SQL, в обход вашей чудной логике. Тут же посылаются к черту ваши тесты над InMemory Database и человек не понимает зачем вообще взялся за это.
Какие-то аггрегации на клиентской части, для меня это вообще дико. О переиспользовании запросов вообще нет речи. Концепция курсоров для меня не расскрыта, что они делают? Тягают данные на клиент???
К черту автоматические миграции
Почему так сразу? Я не говорю, что автомиграции — это «серебряная пуля», но при осмысленном использовании — довольно удобный инструмент. При развитии бизнес-системы 9 из 10 изменений схемы — это добавление новых полей, расширение размеров существующих полей и обновление кода представлений, что является примитивной мишенью для автоматических миграций (а автомиграции умеют много больше). По сути, вы получаете ряд преимуществ разработки со schemaless-базой данных, не получая при этом их недостатков. Да, приходится думать о том, как развивать схему в таком ключе, чтобы автомиграция справилась без посторонней помощи. Но вам в любом случае приходится думать о чём-то подобном: даже если мы выполняем миграции при помощи специальных тулов, рекомендуется отвязывать обновление схемы от обновления приложения, так чтобы приложение было способно работать с разными версиями схемы, так что всегда приходится ограничивать себя.
Если вы отдаляете пользователя от SQL — библиотека в проигрыше
А если не отдаляю — то в проигрыше пользователь! Вернее так: в инженерии не бывает абсолютного выигрыша и абсолютного проигрыша, выигрыш в одном даётся проигрышем в другом. Если вы пишете на нативном SQL, вы выигрываете в доступных функциональных возможностях. Но вы проигрываете, сильнее привязываясь к базе данных и лишаясь возможности быстро её сменить (даже обновиться на новую версию той же БД), лишаясь возможности легко тестировать ваш код, лишаясь поддержки платформы в части централизованного контроля и аудита доступа / модификаций.
Какие-то аггрегации на клиентской части, для меня это вообще дико.
Вы про CelestaSQL materialized views? Кажется, в статье довольно чётко написано, что агрегации происходят именно что на стороне СУБД.
Концепция курсоров для меня не расскрыта, что они делают?
Это кодогенерируемые классы доступа к данным базы данных. Отвечают за чтение/запись данных, см. пример кода `@Service DocumentService` в статье.
С миграциями отдельная тема. Но если чесно, если вы снимаете модель с базы, то и снимайте ее постоянно, а миграции оставьте на продвинутые инструменты. Да и больше времени останется на доработку самой библиотеки.
Где-то я такое видел, извините я дотнетчик, но про ORM поговорить люблю, так как также разрабатываю ORM linq2db. В .NET для этого дела есть эталон — EF Core. Продвинутей вашей либы раз в 10 да и наверняка быстрее. Но написать высокопроизводительное приложение можно только с трудом и вставками голого SQL. Тут все складывается в кучу: для изменеия сущности — надо ее достать из базы (два раундтрипа select + update), вставка тоже за собой тянет (insert + select). Поменять одно поле в 100-а записях — еще та попаболь. Как бы мелочи но это кирпичики к стене от производительности к удобности.
Я думаю об стандартном способе описать запрос, который с трансформациями подганяется под нужную базу. Не все конечно так можно сэмулировать, но 90+% в это попадает.
Тестировать базу моками тоже считаю дикостью и приверженец интеграционных тестов. Записали в эталонную базу, считали, проверили. Там такое иногда выскакивает что никогда и не подумаешь.
А если не отдаляю — то в проигрыше пользователь! Вернее так: в инженерии не бывает абсолютного выигрыша и абсолютного проигрыша, выигрыш в одном даётся проигрышем в другом. Если вы пишете на нативном SQL, вы выигрываете в доступных функциональных возможностях. Но вы проигрываете, сильнее привязываясь к базе данных и лишаясь возможности быстро её сменить (даже обновиться на новую версию той же БД), лишаясь возможности легко тестировать ваш код, лишаясь поддержки платформы в части централизованного контроля и аудита доступа / модификаций.
Где-то я такое видел, извините я дотнетчик, но про ORM поговорить люблю, так как также разрабатываю ORM linq2db. В .NET для этого дела есть эталон — EF Core. Продвинутей вашей либы раз в 10 да и наверняка быстрее. Но написать высокопроизводительное приложение можно только с трудом и вставками голого SQL. Тут все складывается в кучу: для изменеия сущности — надо ее достать из базы (два раундтрипа select + update), вставка тоже за собой тянет (insert + select). Поменять одно поле в 100-а записях — еще та попаболь. Как бы мелочи но это кирпичики к стене от производительности к удобности.
Я думаю об стандартном способе описать запрос, который с трансформациями подганяется под нужную базу. Не все конечно так можно сэмулировать, но 90+% в это попадает.
Тестировать базу моками тоже считаю дикостью и приверженец интеграционных тестов. Записали в эталонную базу, считали, проверили. Там такое иногда выскакивает что никогда и не подумаешь.
миграции оставьте на продвинутые инструменты
Вы посмотрите на 2bass, может, понравится)
для изменеия сущности — надо ее достать из базы (два раундтрипа select + update), вставка тоже за собой тянет (insert + select)
Есть такое дело! Но вставку можно оптимизировать, т. к. современный SQL позволяет делать INSERT....RETURNING одним запросом, и, сколько я помню, в Челесте insert с какой-то версии так и работает.
Поменять одно поле в 100-а записях — еще та попаболь
Ну в смысле, организовать из API вызов
UPDATE foo set bar = '....' WHERE ....? Да, есть такое, но это можно заимплементить на уровне библиотеки тоже (это пока не сделали, но я знаю, как сделать).В целом, Celesta достаточно производительна, сколько мне известно она работает на приложениях с нагрузкой порядка 200 rps на ноду. Претензии пользователей к производительности иногда бывают, мы их решаем. С другой стороны, у всего есть область применения. И для какой-то супер-производительной работы наверное Celesta не очень подходит, т. к. изначально создавалась под задачи быстрой разработки бэкенда для бизнес-приложений.
Тестировать базу моками тоже считаю дикостью и приверженец интеграционных тестов
В Java есть отличная штука — TestContainers (не знаю, делались ли попытки интегрировать её с .NET, мне кажется что это возможно) Во время запуска тестов она стартует в контейнерах настоящие базы данных на время теста и даёт к ним API, как если бы это были просто объекты в памяти. Не знаю, как бы мы разрабатывали Celesta без этой технологии, потому что благодаря прогону одного большого набора тестов на четырёх разных реальных базах данных мы гарантируем interoperability между базами. А те, кто пользуется CelestaTest, уже гоняют тесты бизнес-логики на быстром embedded H2, который не надо даже устанавливать, он подключается через зависимость.
Ну в смысле, организовать из API вызов UPDATE foo set bar = '....' WHERE ....? Да, есть такое, но это можно заимплементить на уровне библиотеки тоже (это пока не сделали, но я знаю, как сделать).
Это надо сделать как и Delete, в основном на это плюются. В нашей ORM практически любой запрос, который вы используете для выбоки, легко превращается в UPDATE, UPDATE FROM, DELETE или INSERT INTO — переиспользование налету.
В Java есть отличная штука — TestContainers
Делаем по старинке, надо тестировать на 15 базах: VMWare. Есть такие базы, которые по другому и не поставишь. Майкросфт дал опенсорсу доступ к Azure Pipelines — вот тут уже можно разыграться и докером доставлять нужное, не все конечно.
С другой стороны, у всего есть область применения. И для какой-то супер-производительной работы наверное Celesta не очень подходит, т. к. изначально создавалась под задачи быстрой разработки бэкенда для бизнес-приложений.
Странно, почему вам не подошел старичек Hibernate. Ну что же, через год другой такие проекты попадают в наши высокооплачиваемые руки ;) И это нормально, чтобы взлететь надо чтобы что-то было. Но к сожалению это палка о двух концах, так как новое поколение так и не выучило SQL и не понмает как RDBMS работает.
Это надо сделать как и Delete, в основном на это плюются
DELETE ... WHERE ... одним запросом есть. С такими операциями другая проблема: на них невозможно реализовать клиентский триггер. Ведь мы же поддерживаем навешивание на таблицы клиентских триггеров — on(Pre|Post)(Update|Insert|Delete). При операциях по одной записи они работают, но при bulk-операциях — они не могут быть вызваны для каждой записи. Не всем пользователям это можно быстро объяснить.Странно, почему вам не подошел старичек Hibernate
Потому что круг задач другой. Вообще я пришёл в Java из ERP-систем, история с Hybernate это про другое. Hybernate это ORM, прекрасно, но нам для быстрого пиления проектов типовых бизнес-систем важно иметь в одном флаконе: идемпотентные миграции, проектирование Database-First, тестирование, кроссбазданческость, срединный слой для аудита/распределения доступа.
Сейчас очень модно использовать для теста бд testcontainers, но тут есть минус - это очень долго- и если тестов много , до бывает деплои растягиваются на час. Недавно смотрел старую презетнтацию, где Celesta была использована в качестве тест фреймворка.Было очень быстро и круто - поэтому вопрос - а можно ли тестить jooq с помощью Celesta
К сожалению, нет: jOOQ это jOOQ, Celesta это Celesta, вы выбираете либо одно либо другое
Да, TC тесты с реальным постгресом сильно проигрывают по скорости тестам с in-memory H2. Можно попробовать заточить ваши тесты для jOOQ для in-memory H2, но нужно быть очень осторожным, чтобы не попасть в проблему связанную с различиями в реализации PostgreSQL и H2 (именно эту проблему решает Celesta, абстрагируясь вообще над всеми поддерживаемыми базами данных)
Sign up to leave a comment.
Celesta 7.x: ORM, миграции и тестирование «в одном флаконе»