Да, дейтивительно можно параметризировать параметры теста, отдельная тема. А вот от json строк предлагаю уйти - мой подход кажется мне гораздо удобнее и универсальнее.
Возможно JPA репозиторий должен работать с разного рода вендорами баз данных и неизвестно, как они реализуют транзакционность одиночных команд типа select. Для Postgres и, судя по Discuss about the optimization, для MySQL это может быть оверхед. Ссылка в баге на Hibernate устарела, вот верная
Те мы свои кастомные getByIsbn методы чтения можем делать без транзакций, а стандартные data-jpa все равно с флагом readOnly пойдут. Можете переоткрыть issue со своими выкладками - будет аргумент для архитекторов, если протолкнуть. Но там вряд ли согласятся...
Отвечу так: текущий уровень абстракции подходит под любой проект и любое решение. Далее никто вам не мешает кастомизировать его под себя. Например в микросервисах BaseService скорее всего будет лишним. Про BaseEntity - я в нем выбрал @Access(AccessType.FIELD), Lombook и OpenAPI. Естественно, что Spring Data не может это внести себе в зависимости. Он предоставляет выбор всем, далее - сделай, как ты это используешь. По поводу Mapstruct - что это фреймворк чисто для маппинга. Мой интерфейс выводит его на уровень абстракции выше его задачи - для связки сервиса и контроллера.
Можно без проблем на этом базовом коде файлы грузить. Мы же ничем не ограничиваем контроллеры и сервисы. JHipster - я ее немного пробовал, она опять про автогенерацию, насколько знаю. + если совсем не вписывается - то просто BaseService для этого контроллера не использовать.... @Rion333 - еще такой вопрос-без учета BaseService (BaseTo, BaseMapper, BaseEntity, WebUtil) - тоже синьору повредит?
Вы не поняли статьи или сути Spring Data REST, я делаю все вручную, никаких автогенераций кода. НО без дублирования кода - композиция, наследование, стратегия и дженерики.
Ну да, все верно- код выше как раз ближе всего к слою абстрации для большого монилита, можно вынести в модуль common. В Data REST кроме ресурсов на выходе делать маппинг на урове проекций очень муторно. И совсем некастомизируемо, например кэширование в сервисах или енкодинг пароля приходится чз приседания с Jackson делать. Используя абстракцию вы ничем не связаны- собственный биндинг, валидация, кэширование, настраиваемый маппинг и пр. фишки Spring, Mapstruct и просто Java кода.
См ответ выше + у нас не простой CRUD- любые методы в репозиториях и контроллерах поддерживаются. Суть - не дублировать код на основе общих методов и маппинга.
У себя на сайте они пишут, что с hashCode от ID будут проблемы, если сначала был NULL, а затем после сохранения появился ID, сгенерированный БД:
"Once the id is generated (on its first save) the hashCode gets changed. So the HashSet looks for the entity in a different bucket and cannot find it. It wouldn’t be an issue if the id was set during the entity object creation (e.g. was a UUID set by the app), but DB-generated ids are more common."
Простите, рука дрогнула, был вопрос про сложность использования. Ответ такой:
Сложно ли пользоваться Spring Data Jpa? Упрощает ли он работу?
Смотрели ли вы внутрь него, как он реализован?
Я к тому, что для использования предложенного подхода вам нужно только делать код контроллера в конце статьи, что проще для понимания и использования, чем традиционный подход
Если посмотрите - сам контроллер у меня не параметризирован + есть возможность напрямую вызывать специфичные методы репозитория и настраивать маппинг. Попробуйте попользовать и жду фидбэка- что не получилось сделать
Спасибо за комментарий! Ссылку на коллекции Kotlin добавил (https://kotlinlang.org/docs/collections-overview.html). По остальному - буду рад или ресурсам или подробному комментарию, тк на это натыкаешься уже в процессе работы, не на простой миграции.
У меня не было такой необходимости. А зачем при XML/JAXB аннотация на package? На Java курсе Работа с документами в Java (https://habr.com/ru/articles/765332/) не было такой надобности.
Даже работая на дядю, я всегда работал на себя. Вкладывался в себя, смотрел на проф. рост. Когда я перерастал компанию- уходил, хотя было непролсто и просили остаться.
Даже работая - постоянно мониторил рынок: ск-ко я там стою, что нужно на рынке, какие тенденции
На собеседования всегда ходил с удовольствием и интересом, см.2. Были иногда неприятные собеседования, безо всякой для меня пользы, но таких было немного
Тестовое беру, если это мне интересно и я от него проф. вырасту.
По поводу вкатиться- да, сейчас сложно, просто вывесить резюме недостаточно. Ищите пути: пришите HR, друзьям, коллегам, участвуйте в тусовках.
Пет проекты нужны обязательно, если нет коммерческого опыта. Если он есть - достаточно описания своей роли и технологий в проектах, гду участвовал.
Как вариант - мы в своем боте тестирование знаний Java сделали множественный выбор на основе неанонимной голосовалки: https://t.me/JavaOPsTestBot
Да, дейтивительно можно параметризировать параметры теста, отдельная тема.
А вот от json строк предлагаю уйти - мой подход кажется мне гораздо удобнее и универсальнее.
В spring-data-jpa проекте есть такой код:
И есть на него закрытая бага не открывать по умолчанию транзакцию на чтение.
Возможно JPA репозиторий должен работать с разного рода вендорами баз данных и неизвестно, как они реализуют транзакционность одиночных команд типа select. Для Postgres и, судя по Discuss about the optimization, для MySQL это может быть оверхед. Ссылка в баге на Hibernate устарела, вот верная
Те мы свои кастомные getByIsbn методы чтения можем делать без транзакций, а стандартные data-jpa все равно с флагом readOnly пойдут. Можете переоткрыть issue со своими выкладками - будет аргумент для архитекторов, если протолкнуть. Но там вряд ли согласятся...
Отвечу так: текущий уровень абстракции подходит под любой проект и любое решение. Далее никто вам не мешает кастомизировать его под себя.
Например в микросервисах BaseService скорее всего будет лишним.
Про BaseEntity - я в нем выбрал @Access(AccessType.FIELD), Lombook и OpenAPI. Естественно, что Spring Data не может это внести себе в зависимости. Он предоставляет выбор всем, далее - сделай, как ты это используешь.
По поводу Mapstruct - что это фреймворк чисто для маппинга. Мой интерфейс выводит его на уровень абстракции выше его задачи - для связки сервиса и контроллера.
Коммент ниже про кастомизацию еще посмотрите:)
Можно без проблем на этом базовом коде файлы грузить. Мы же ничем не ограничиваем контроллеры и сервисы. JHipster - я ее немного пробовал, она опять про автогенерацию, насколько знаю. + если совсем не вписывается - то просто BaseService для этого контроллера не использовать....
@Rion333 - еще такой вопрос-без учета BaseService (BaseTo, BaseMapper, BaseEntity, WebUtil) - тоже синьору повредит?
Вы не поняли статьи или сути Spring Data REST, я делаю все вручную, никаких автогенераций кода. НО без дублирования кода - композиция, наследование, стратегия и дженерики.
Ну да, все верно- код выше как раз ближе всего к слою абстрации для большого монилита, можно вынести в модуль common. В Data REST кроме ресурсов на выходе делать маппинг на урове проекций очень муторно. И совсем некастомизируемо, например кэширование в сервисах или енкодинг пароля приходится чз приседания с Jackson делать. Используя абстракцию вы ничем не связаны- собственный биндинг, валидация, кэширование, настраиваемый маппинг и пр. фишки Spring, Mapstruct и просто Java кода.
См ответ выше + у нас не простой CRUD- любые методы в репозиториях и контроллерах поддерживаются. Суть - не дублировать код на основе общих методов и маппинга.
Spring Data REST - это вообще не про это
Это Hateoas, который генерит код на основе репозиториев. Там как раз невозможно ничего кастомизировать
Все это очень проекто-специфично
Никто не мешает отнаследоваться от BaseService и вызывать репозиторий оттуда
Это не критика, за удобство JPA приходиться платить. Обычно не критично, но, как всегда, думаю есть особые случаи.
Да. По ссылке jpa buddy посмотрите
У себя на сайте они пишут, что с hashCode от ID будут проблемы, если сначала был NULL, а затем после сохранения появился ID, сгенерированный БД:
"Once the id is generated (on its first save) the hashCode gets changed. So the HashSet looks for the entity in a different bucket and cannot find it. It wouldn’t be an issue if the id was set during the entity object creation (e.g. was a UUID set by the app), but DB-generated ids are more common."
Простите, рука дрогнула, был вопрос про сложность использования. Ответ такой:
Сложно ли пользоваться Spring Data Jpa? Упрощает ли он работу?
Смотрели ли вы внутрь него, как он реализован?
Я к тому, что для использования предложенного подхода вам нужно только делать код контроллера в конце статьи, что проще для понимания и использования, чем традиционный подход
Если посмотрите - сам контроллер у меня не параметризирован + есть возможность напрямую вызывать специфичные методы репозитория и настраивать маппинг. Попробуйте попользовать и жду фидбэка- что не получилось сделать
@stalkermustang
А можно поподробнее про "ИИ пройдет тест на самосознание в зеркале". Судя по картинке- уже прошло?
Где почитать?
Спасибо за комментарий! Ссылку на коллекции Kotlin добавил (https://kotlinlang.org/docs/collections-overview.html). По остальному - буду рад или ресурсам или подробному комментарию, тк на это натыкаешься уже в процессе работы, не на простой миграции.
У меня не было такой необходимости. А зачем при XML/JAXB аннотация на package? На Java курсе Работа с документами в Java (https://habr.com/ru/articles/765332/) не было такой надобности.
Средний уровень Java для начинающих на Kotlin - так подразумевалось:)
Спасибо, посмотрю на возможности
Напишу про себя:
Даже работая на дядю, я всегда работал на себя. Вкладывался в себя, смотрел на проф. рост. Когда я перерастал компанию- уходил, хотя было непролсто и просили остаться.
Даже работая - постоянно мониторил рынок: ск-ко я там стою, что нужно на рынке, какие тенденции
На собеседования всегда ходил с удовольствием и интересом, см.2. Были иногда неприятные собеседования, безо всякой для меня пользы, но таких было немного
Тестовое беру, если это мне интересно и я от него проф. вырасту.
По поводу вкатиться- да, сейчас сложно, просто вывесить резюме недостаточно. Ищите пути: пришите HR, друзьям, коллегам, участвуйте в тусовках.
Пет проекты нужны обязательно, если нет коммерческого опыта. Если он есть - достаточно описания своей роли и технологий в проектах, гду участвовал.