Comments 16
Надо попробовать (хотя я обычно NetBeans юзаю), автоматизация рутины - это наше всё, с БД этой рутины много, ещё и накосячить легко
Чем мне нравится .net, там не надо изобретать велосипедов для простой миграции. И да, угадывать СУБД тоже не надо ;)
В чем liquibase - велосипед? Обычное, удобное средство для миграции. Причем для миграции любой сложности. Есть встроенный JPA инструмент для простых миграций. Не понимаю, чего там в .net сверх такого, отличающегося от описанного liquibase, что явно лучше и удобнее, что потребовался ваш уничижительный комментарий в сторону джава инструментариев?
Про угадывание субд тоже не понял, что имеется в виду
Ничего личного, но "dotnet ef migrations add XXX" и "dotnet ef database update" делают вроде тоже самое, но работают из коробки и кажутся мне проще.
Про угадывание субд тоже не понял, что имеется в виду
А поменяйте в вашем примере в настройках Postgres на какой-нибудь T-SQL ;) В dotnet всё, что придётся сделать, это поменять пакет. Код править не придётся. В Spring, насколько я помню, я должен знать, у кого там в sql update на самом деле upsert, а у кого merge, или как получить автоинкрементированный номер только что вставленой записи.
Ну или попробуйте поддерживать пару разных разных СУБД в одном проекте со всеми этими миграциями.
Так в spring jpa просто одна опция - auto-ddl=update и она сама разрулит миграции. Но там много подводных камней и подходит для элементарных обновлений. Я уверен что в .net тоже самое, какие-то сложные миграции вы без выверенной последовательности действий вы не сделаете. А это надо будет уже писать ручками эти последовательности. Хотя могу ошибаться, не работал с дотнетом, но с трудом верится в интеллектуальность одной команды, так чтобы ввел и все разрулилось как мне нужно.
Насчет поддержки - поддерживал и две и три БД одновременно, правда через Flyway, но уверен что и Liquibase такое есть
Чтобы сделать это быстро, начните печатать
ddl-autoи Amplicode предложит вам соответствующее свойство.
Это все же не Amplicode предложит, а сам IDEA. У меня при редактировании проперти файлов и без Amplicode выходят подсказки. А так ваш инструмент конечно нужный и полезный, который значительно облегчает выполнение рутинных действий. Хотя с другой стороны сколько новых формошлепов он взрастит, которые уже без вашего инструмента сами сделать ничего не смогут, ибо будут не понимать что там под капотом
Это все же не Amplicode предложит, а сам IDEA
Ultimate IDEA может и предложит, только ее не скачать уже легально
А вот Community IDEA, или тот же GigaIDE, уже нет (если конечно не поставить на них Amplicode)
Хотя с другой стороны сколько новых формошлепов он взрастит
IDE умнеют с каждым годом, и от этого никуда не уйти. Взращивает ли это формошлепов? Не думаю. Порог входа снижается, да. В любом случае, ответственность за код несет разработчик, который его закоммитил. Не важно, где он его взял, на stackoverflow, chatgpt или сгенерировал с помощью Amplicode.
Если у вас Ultimate, то да это фича IntelliJ IDEA Ultimate. Я всё показывал на IntelliJ IDEA Community Edition, так такой фичи из коробки нет.
Касаемо формошлёпства, не совсем согласен. По моему опыту, сильно чаще разработчики бездумно копируют неправильный код со StackOverflow или из других частей проекта не особо вникая в его суть. Например, я недавно рассказывал про CascadeType.ALL с ManyToMany.
Можно подумать, что так никто не делает, но вот 45 000 найденных результатов по запросу "@ManyToMany CascadeType.ALL" на GitHub выглядят страшновато)
Мы же стараемся максимально проанализировать какой код стоит генерировать в тех или иных ситуациях. И допустить потенциальную ошибку с нашим инструментом вероятность сильно меньше, на мой взгляд. Ну и никто же не запрещает проанализировать тот код, который был сгенерирован. Тут скорее вопрос а будут ли так делать, и наша ли в этом вина если не будут?
Соглашусь. В формошлепстве в первую очередь виноват разработчик, который не умеет анализировать сгенерированный текст. Всякие ЧатЖПТ так вообще генерируют код, который часто неверный. И как выше Александр сказал - IDE умнеют и никуда не деться.
Про ваш рассказ CascadeType.ALL не вижу. Ссылка не работает.
Про 45 тысяч использований интересно) Может быть стоит дать больше огласки этой теме
Да, что-то я накосячил. Продублирую: Никогда не используй CascadeType.ALL вместе с @ManyToMany
Поэтому надо как можно меньше люфта давать обычным разработчикам, чтобы не было места креативу в важных местах
Не всегда эти nocode инструменты делают то, что надо и мне показалось, что быстрее код написать, чем кликать в этом инструменте, надо проверить, спасибо за обзор.
А что делать, если вам надо удалить атрибут, но в бд оставить его ещё на пару версий(обновлений) ? Чтобы откат был безболезненным.
Lombok позволяет не писать getter/setters и др, добавляет нормальные конструкторы, все это делает код более читабельным... Позволяет ли эта штука работать с ним?
А как с maven? Не люблю градл в Java проектах
мне показалось, что быстрее код написать, чем кликать в этом инструменте
В некоторых моментах, возможно. Например, когда надо добавить какой нибудь простой атрибут в JPA сущность. Но вот если добавлять какой нибудь ассоциативный атрибут, тут, как по мне, больше времени уйдет, потому что я по памяти просто не вспомню как он пишется и придётся идти гуглить :)
> А что делать, если вам надо удалить атрибут, но в бд оставить его ещё на пару версий(обновлений)?
Если вопрос конкретно про Amplicode, то можно на время, пока вы не хотите видеть это изменение в автоматической генерации пометить его как игнорируемое. И потом, спустя несколько версий, убрать его из списка заигноренных.
> Lombok позволяет не писать getter/setters и др, добавляет нормальные конструкторы, все это делает код более читабельным... Позволяет ли эта штука работать с ним?
Да, конечно, Amplicode учитывает наличие Lombok в проекте. Более того, он ещё во многих местах подскажет, где Lombok лучше не использовать совсем или использовать иначе, тоже снимал про это отдельное видео, если интересно можете глянуть: https://youtu.be/7kdQTh4oOQM?feature=shared
> А как с maven? Не люблю градл в Java проектах
Всё будет работать точно также :)
Вообще, можно ещё вот этот видос 7-минутный глянуть, там я постарался в общих чертах объяснить философию инструмента, думаю после этого сложиться чуть более цельная картинка про Amplicode :) https://youtu.be/7vIX8vbT3kM?feature=shared
Ну и готов ответить на любые вопросы, которые возникнут в процессе изучения инструмента)
Liquibase + Spring Boot: настройка и написание миграций баз данных