ну или индекс заябошить какой-то

Можешь, но это хуёвое решение.

я думаю какой-бы пример привести, где нужно все за раз вставить...

типа какого-то случая, когда насоздавал кучу ингредиентов, которые не привязаны к какому-либо блюду

На практике у ресторанов не будет огромной номенклатурной группы ингредиентов, готовят из одного и того же, просто разные блюда

Дрочь какая-то

Я делаю проект для себя и для изучения jpa, в моих интересах понять как решать разные возможные проблемы. И первый тренировочный проект я решил сделать с этой базой ингредиентов-блюд. Что-то тяжковато идет честно говоря. Ну я как бы уже реализовал вставку, как вы предлагаете - по частям, но получилось так процедурно и не maintainable, что я сразу решил все переписать

Если что, можно повесить вышеописанную логику  на фронт. Тем более если кто-то очепятается в названии ингредиента, тот уже будет создан.
На фронте же можно искать по названию и брать id. Если что-то не найдётся, то юзер может заметить, что очепятался.

Просто нужно ui сделать чтоб все ингредиенты отображались в подгруппах, чтоб не допустить создания дублей. Заходишь в подгруппу мясо - видишь там все виды мяса и тд

Естественно, тогда будет тоже select by name, но если клиент будет кэшировать ингредиенты, то после первого select не будет мгновенных последующих того же самого ингредиента. Зато у нас на бэке останется добавление по id, что очень удобно.

По поводу прав - оказывается есть же возможность экспорта чата - я пошел этим путем, выгружаю сейчас в формате JSON, буду смотреть, как его обработать

Потому что очень часто, нужно создать более одной энтити, связанной между собой. Артем хочет в целом узнать, а не только про конкретный случай.

А примером может быть, когда внешняя система присылает строку, которая для нашей системы код справочника(но не первичный ключ). И в таком случае мы в сервисе сделаем запрос, найдем наш ключ и поставим связь в ентити. Случай когда такую новую запись на лету нужно создать, тоже может иметь место быть

Как пишут коллеги, дто, которое идёт с ui, чаще оперирует уже id-шниками созданных сущностей/справочников.
В твоём домене удобно вернуть и передавать уже id. Но в целом, при необходимости, можно в одной транзакции создать несколько сущностей. Используя jpa, ты можешь указать связи на сущностях, что позволит сохранить сущности сразу со связями между друг другом. И даже использовать каскад(чтобы при сохранении сущности, все сущности связанные с ней тоже сохранились/удалились)

Почему при создании пакета можно создать только один публичный класс? Как тогда работают другие пакеты, в которых множество доступных классов? Или можно обратиться как-то к непубличному классу после импорта пакета?

Ээ, что? Где можно создать только один публичный класс при создании пакета? Это не так.

Разве нет требования, чтобы объявление публичного класса находилось в файле с тем же именем, которое присвоено классу?
Или пакет можно оформить просто множеством файлов?

Пакет это папка, а класс находится в файле класса.

В одном пакете может быть множество файлов классов публичных.

наобещали в 15 jdk фиберы, и где они 🥺