понял

Какая у меня в голове каша? Говорю же: изучаю вот это. А ты мне: делай миграции. Ну, нет вот в этом миграций. Ан нет каша в голове именно у меня.

да у тебя

ты даже не понимаешь проблему и что я тебе пытаюсь сказать

Потому что не включена опция по генерации схемы. У тебя провадер JPA какой?

spring data jpa - это специальный апи для работы с рсудб,внутри у него ORM-провайдер, по умолчанию Hibernate;

с помощью специальной проперти hibernate.hbm2ddl.auto=create (примерно по памяти), ты генеришь таблички в базе (схему) из pojo

то есть у тебя состоянием базы (миграциями) управляет хибернейт

я тебе говорю, это не продакшен решение и плохая практика

и миграции надо делать самому через инструменты вроде flyway/liquibase, а хибернейт переводить в режим валидации

твой изначальный вопрос - как заставишь хибер генерить индексы из коды, мой ответ тебе - тебе вообще не надо ничего генерить из кода, это юзлесс навык абсолютно

А я еще раз говорю, что я изучаю Spring Data JPA. Изучаю. А не делаю продуктивный код.

Spring Data JPA не имеет отношения к генерации схемы

если что

spring-boot-starter-parent 2.4.0
spring-boot-starter-data-jpa


В application.properties:
spring.jpa.hibernate.ddl-auto=create-drop

Изменения в POJO находят отражение в БД. Но вот сделать индекс на слаг что-то не получилось.

Хм. В общем, я переименовал индекс - добавил уникальный префикс к имени индекса на слаг соответствующей таблицы. И все заработало. Ну, чудеса.

К миграциям я приду. Но я вот это вот пока очень плохо понимаю. Я понимаю - да, миграции - это важно. Да, на проде надо их делать.

Но я пришел с другого фреймворка. Там миграции генерировались командой. Сделал модель, запустил скрипт, сгенерились миграции.

А здесь попробовал миграции - надо вручную, вроде бы. Вот и ты тут говоришь, что надо вручную. А как его вручную сделать - ума не приложу. Ну, бывают же сложные таблицы. Это сначала продумывать POJO. Потом продумывать еще к нему SQL. Зачем два раза делать одну и ту же работу? Которая еще к тому же будет сделана плохо. А ведь так и будет, где-нибудь вылезет обязательно боком, что два раза в разных местах над одним и тем же думал, пытался срастить, а оно, допустим, срослось плохо.

Можно было бы вывести SQL  влог и взять оттуда SQL для миграций. Но команды SQL в логе не оказалось. Просто по факту ее там нет. Есть какие-то обрывки команд что-ли: сначала создает таблицу. Потом кидает индексы. Потом кидает ограничения. Ну, получается, что команды-то и нет.

Выглядит примерно так: https://pastebin.com/LxawqCHp

Т.е. конкретной команды что-то тут не видно. Или хотя бы последовательности команд.

Смотрю видос https://www.youtube.com/watch?v=7uxROJ1nduk&ab_channel=EugeneSuleimanov. Не могу понять, зачем в jwt он сетает claim role. Она не используется вообще. Используется только claim sub. При каждом запросе не на логин по sub из jwt вытаскивается юзер из БД и кладётся в SecurityContext как Authorization. Тогда какие вообще преимущества jwt перед sessionId конкретно в данном случае?

при подходе с миграциями, ты сначала пишешь sql код миграций, а потом конструируешь jpa-энтити вручную по ним

корректность проверяешь интеграционными тестами и validate стратегией хибера

это сколько же надо писать просто ради миграций? Которых на других фреймворках просто не замечаешь. Они есть по факту. Как воздух: пока не испортишь - не заметишь. Вот в спринге испорчено что-ли. Кто это придумал, нафиг.