Там хитрый лендинг) Это только для IntelliJ IDEA Ultimate так, но есть пролистать вниз на этой странице: https://www.jetbrains.com/idea/download, то там можно будет выбрать IntelliJ IDEA Community Edition и она скачается без проблем.
Да, всё так. Ну и, кстати, JPA Buddy – тоже наша разработка :) Теперь она находится "под крылом" JetBrains, а функциональность, которая ранее была реализована в JPA Buddy переехала в Amplicode.
Да, про то что JPA != Hibernate – хорошее замечание, согласен, что стоило это отметить в начале статьи. Учту на будущее :)
Для EclipseLink Amplicode генерирует реализацию методов придерживаясь схожего принципа, но используя org.springframework.data.util.ProxyUtils#getUserClass(java.lang.Object):
@Override
public final boolean equals(Object o) {
if (this == o) {
return true; } if (o == null || ProxyUtils.getUserClass(this) != ProxyUtils.getUserClass(o)) {
return false; } Climber climber = (Climber) o; return getId() != null && Objects.equals(getId(), climber.getId()); }
@Override
public final int hashCode() {
return ProxyUtils.getUserClass(this)
.hashCode(); }
Да, согласен, похожая статья уже была. Основные тезисы тут остались примерно такими же, но добавили больше примеров, а также более детально рассмотрели работу методов equals() и hashCode(). Ну и новый инструмент заюзали, чтобы решить все проблемы с которыми столкнулись :)
На самом деле, у нас сейчас все версии – EAP. Я поэтому и не указал EAP в названии статьи, хотя возможно и стоило)
Но в целом, этот EAP-постфикс у нас будет во всех версиях, которые будут опубликованы в этом году.
При этом всё доступно, версии довольно стабильные (по крайней мере те обращения, которые мы получаем в телеграм-чате не носят критический характер), на сайте информация актуальная, касаемо магазина плагинов я не совсем понял о чём именно речь. Если речь про наш маркетплейс, который можно указать в IDE, как описано в рекомендуемом способе установки, то с ним обновление также проходит успешно.
Если предпочитаете не указывать наш маркетплейс, а следить за обновлениями вручную и использовать архивы, то их я тоже опубликовал, можно на GitHub найти.
Если вдруг какие-то проблемы возникнут с установкой/обновлением – всегда готов помочь :)
1) Да, всё это дело настраиваемое и каждый может настроить под свой проект
2) На вашем проекте instanceof подходит, на других не подойдёт. В целом, мы можем посмотреть в сторону того, чтобы дать возможность генерировать несколько реализацией. Но нужно провести анализ и убедиться, что действительно не будет никаких сайд эффектов в случае использования этого подхода. С той реализацией которую мы генерируем, проблем точно не будет, хоть она и может выглядеть как "портянка" :)
Дело в том, что некоторые из предустановленных плагинов были заброшенными open-source проектами, в которых не фиксились баги и которые перестали быть доступны на новых версиях IntelliJ. Сбер как минимум сделал эти плагины совместимыми с новой версией IntelliJ, ну и надеюсь что какие-то багофиксы тоже принёс)
Насколько я понял из выступления ребята из Сбера на Гигаконф, текущая версия GigaIDE будет бесплатной и будет называться Community Edition. А к концу 2024 года планируется к выходу GigaIDE Pro, которая будет платной. В общем, по аналогии с IntelliJ, по всей видимости. Касаемо лицензии и открытости/закрытости кода сказать не могу.
мне показалось, что быстрее код написать, чем кликать в этом инструменте
В некоторых моментах, возможно. Например, когда надо добавить какой нибудь простой атрибут в JPA сущность. Но вот если добавлять какой нибудь ассоциативный атрибут, тут, как по мне, больше времени уйдет, потому что я по памяти просто не вспомню как он пишется и придётся идти гуглить :)
> А что делать, если вам надо удалить атрибут, но в бд оставить его ещё на пару версий(обновлений)?
Если вопрос конкретно про Amplicode, то можно на время, пока вы не хотите видеть это изменение в автоматической генерации пометить его как игнорируемое. И потом, спустя несколько версий, убрать его из списка заигноренных.
> Lombok позволяет не писать getter/setters и др, добавляет нормальные конструкторы, все это делает код более читабельным... Позволяет ли эта штука работать с ним?
Да, конечно, Amplicode учитывает наличие Lombok в проекте. Более того, он ещё во многих местах подскажет, где Lombok лучше не использовать совсем или использовать иначе, тоже снимал про это отдельное видео, если интересно можете глянуть: https://youtu.be/7kdQTh4oOQM?feature=shared
> А как с maven? Не люблю градл в Java проектах
Всё будет работать точно также :)
Вообще, можно ещё вот этот видос 7-минутный глянуть, там я постарался в общих чертах объяснить философию инструмента, думаю после этого сложиться чуть более цельная картинка про Amplicode :) https://youtu.be/7vIX8vbT3kM?feature=shared
Ну и готов ответить на любые вопросы, которые возникнут в процессе изучения инструмента)
Если у вас Ultimate, то да это фича IntelliJ IDEA Ultimate. Я всё показывал на IntelliJ IDEA Community Edition, так такой фичи из коробки нет.
Касаемо формошлёпства, не совсем согласен. По моему опыту, сильно чаще разработчики бездумно копируют неправильный код со StackOverflow или из других частей проекта не особо вникая в его суть. Например, я недавно рассказывал про CascadeType.ALL с ManyToMany. Можно подумать, что так никто не делает, но вот 45 000 найденных результатов по запросу "@ManyToMany CascadeType.ALL" на GitHub выглядят страшновато)
Мы же стараемся максимально проанализировать какой код стоит генерировать в тех или иных ситуациях. И допустить потенциальную ошибку с нашим инструментом вероятность сильно меньше, на мой взгляд. Ну и никто же не запрещает проанализировать тот код, который был сгенерирован. Тут скорее вопрос а будут ли так делать, и наша ли в этом вина если не будут?
Если время от времени приходится писать скрипты миграции, то обязательно попробуйте. Думаю, сэкономите много времени :) Если возникнут какие-то вопросы по инструменту, всегда будем рады помочь в чате в тг (https://t.me/amplicode_chat)
спасибо! поправил
К Ultimate да, Ultimate недоступна с любых страниц, в том числе по этой причине в статье рассказывал только про фичи Community Edition
Там хитрый лендинг) Это только для IntelliJ IDEA Ultimate так, но есть пролистать вниз на этой странице: https://www.jetbrains.com/idea/download, то там можно будет выбрать IntelliJ IDEA Community Edition и она скачается без проблем.
Альтернативно можно вот эту страницу использовать: https://www.jetbrains.com/idea/download/other.html, тут сразу понятно где Ultimate, а где Community, на мой взгляд.
Спасибо! Я поправил в теле статьи, на всякий случай ещё сюда продублирую: https://github.com/Amplicode/amplicode-tutorials/tree/main/lombok-pitfalls
Да, что-то я не то выделил на картинке ещё :)
Спасибо! Поправил
Да, всё так. Ну и, кстати, JPA Buddy – тоже наша разработка :) Теперь она находится "под крылом" JetBrains, а функциональность, которая ранее была реализована в JPA Buddy переехала в Amplicode.
Спасибо :)
Добрый день, спасибо)
Да, про то что JPA != Hibernate – хорошее замечание, согласен, что стоило это отметить в начале статьи. Учту на будущее :)
Для EclipseLink Amplicode генерирует реализацию методов придерживаясь схожего принципа, но используя
org.springframework.data.util.ProxyUtils#getUserClass(java.lang.Object):@Override public final boolean equals(Object o) { if (this == o) { return true;}
if (o == null || ProxyUtils.getUserClass(this) != ProxyUtils.getUserClass(o)) { return false;
}
Climber climber = (Climber) o;
return getId() != null && Objects.equals(getId(), climber.getId());
} @Override public final int hashCode() { return ProxyUtils.getUserClass(this) .hashCode();
}
Да, согласен, похожая статья уже была. Основные тезисы тут остались примерно такими же, но добавили больше примеров, а также более детально рассмотрели работу методов
equals()иhashCode(). Ну и новый инструмент заюзали, чтобы решить все проблемы с которыми столкнулись :)Добрый день!
На самом деле, у нас сейчас все версии – EAP. Я поэтому и не указал EAP в названии статьи, хотя возможно и стоило)
Но в целом, этот EAP-постфикс у нас будет во всех версиях, которые будут опубликованы в этом году.
При этом всё доступно, версии довольно стабильные (по крайней мере те обращения, которые мы получаем в телеграм-чате не носят критический характер), на сайте информация актуальная, касаемо магазина плагинов я не совсем понял о чём именно речь. Если речь про наш маркетплейс, который можно указать в IDE, как описано в рекомендуемом способе установки, то с ним обновление также проходит успешно.
Если предпочитаете не указывать наш маркетплейс, а следить за обновлениями вручную и использовать архивы, то их я тоже опубликовал, можно на GitHub найти.
Если вдруг какие-то проблемы возникнут с установкой/обновлением – всегда готов помочь :)
@vasyakolobok77 спасибо за развёрнутый комментарий!
Полностью согласен с @alexander-shustanov, лишь дополню:
1) Да, всё это дело настраиваемое и каждый может настроить под свой проект
2) На вашем проекте instanceof подходит, на других не подойдёт. В целом, мы можем посмотреть в сторону того, чтобы дать возможность генерировать несколько реализацией. Но нужно провести анализ и убедиться, что действительно не будет никаких сайд эффектов в случае использования этого подхода. С той реализацией которую мы генерируем, проблем точно не будет, хоть она и может выглядеть как "портянка" :)
По 3 и 4 пунктам добавить нечего.
Для работы с open api я нашел только плагин Zalando OpenAPI Editor, он preview не предоставляет, только удобное редактирование
С одной стороны да, с другой стороны нет.
Дело в том, что некоторые из предустановленных плагинов были заброшенными open-source проектами, в которых не фиксились баги и которые перестали быть доступны на новых версиях IntelliJ. Сбер как минимум сделал эти плагины совместимыми с новой версией IntelliJ, ну и надеюсь что какие-то багофиксы тоже принёс)
Да, всё так. В Giga IDE такого пока что нет, как и в Community Edition
Хорошее замечание, спасибо! Возможно стоит сделать отдельный обзор на GigaChat
Насколько я понял из выступления ребята из Сбера на Гигаконф, текущая версия GigaIDE будет бесплатной и будет называться Community Edition. А к концу 2024 года планируется к выходу GigaIDE Pro, которая будет платной. В общем, по аналогии с IntelliJ, по всей видимости. Касаемо лицензии и открытости/закрытости кода сказать не могу.
В некоторых моментах, возможно. Например, когда надо добавить какой нибудь простой атрибут в JPA сущность. Но вот если добавлять какой нибудь ассоциативный атрибут, тут, как по мне, больше времени уйдет, потому что я по памяти просто не вспомню как он пишется и придётся идти гуглить :)
> А что делать, если вам надо удалить атрибут, но в бд оставить его ещё на пару версий(обновлений)?
Если вопрос конкретно про Amplicode, то можно на время, пока вы не хотите видеть это изменение в автоматической генерации пометить его как игнорируемое. И потом, спустя несколько версий, убрать его из списка заигноренных.
> Lombok позволяет не писать getter/setters и др, добавляет нормальные конструкторы, все это делает код более читабельным... Позволяет ли эта штука работать с ним?
Да, конечно, Amplicode учитывает наличие Lombok в проекте. Более того, он ещё во многих местах подскажет, где Lombok лучше не использовать совсем или использовать иначе, тоже снимал про это отдельное видео, если интересно можете глянуть: https://youtu.be/7kdQTh4oOQM?feature=shared
> А как с maven? Не люблю градл в Java проектах
Всё будет работать точно также :)
Вообще, можно ещё вот этот видос 7-минутный глянуть, там я постарался в общих чертах объяснить философию инструмента, думаю после этого сложиться чуть более цельная картинка про Amplicode :) https://youtu.be/7vIX8vbT3kM?feature=shared
Ну и готов ответить на любые вопросы, которые возникнут в процессе изучения инструмента)
Да, что-то я накосячил. Продублирую: Никогда не используй CascadeType.ALL вместе с @ManyToMany
Если у вас Ultimate, то да это фича IntelliJ IDEA Ultimate. Я всё показывал на IntelliJ IDEA Community Edition, так такой фичи из коробки нет.
Касаемо формошлёпства, не совсем согласен. По моему опыту, сильно чаще разработчики бездумно копируют неправильный код со StackOverflow или из других частей проекта не особо вникая в его суть. Например, я недавно рассказывал про CascadeType.ALL с ManyToMany.
Можно подумать, что так никто не делает, но вот 45 000 найденных результатов по запросу "@ManyToMany CascadeType.ALL" на GitHub выглядят страшновато)
Мы же стараемся максимально проанализировать какой код стоит генерировать в тех или иных ситуациях. И допустить потенциальную ошибку с нашим инструментом вероятность сильно меньше, на мой взгляд. Ну и никто же не запрещает проанализировать тот код, который был сгенерирован. Тут скорее вопрос а будут ли так делать, и наша ли в этом вина если не будут?
Если время от времени приходится писать скрипты миграции, то обязательно попробуйте. Думаю, сэкономите много времени :) Если возникнут какие-то вопросы по инструменту, всегда будем рады помочь в чате в тг (https://t.me/amplicode_chat)