Задача отличать сущности друг от друга до их вставки в базу, для этого знать id, да

изначальный вопрос как быть если хочется иметь объект в приложении для сущности чей жизненный цикл данных (включая идентификатор) не привязан к хранилищу. Мол что это не совсместимо с автоинкрементами (что справедливо например для mysql если решать вопрос в лоб)

Это видимо вопрос про то как у вас эти новые пользователи в коде живут - если есть какое то свое хранилище то я бы держал локальные ключи которые либо подменяются после вставки в базу либо просто всегда живут отдельно но если есть ключ базы то на локальные не смотрим.

Если это просто объекты - то  ссылками бы обошёлся.

Оба варианта с геморроем потом, но хороший не уверен что существует.

Лучше и не скажешь)

Это точно не будет совместимо с автоинкрементами как и вообще мало что. Особенно если параллельные запросы в базу учитывать - автоинкременты не выживут

Получается, автоинкремент для независимости от базы не походит от слова совсем, а uuid - исключительное решение

Просто не хочется мыслить бинарно. Неужели и в правду, uuid - решение всех проблем?

автоинкремент, кроме прочего, еще и не особо с точки зрения безопасности - он раскрывает примерное количество записей в таблице

любой хороший генератор уникальных ключей подойдет

Может быть выгодно держать в приложении логику которая мапит локальные ключи в ключи БД.

Например позволит вам накручивать всякую логику частичной записи, ретраев и т.д. но это у вас слой хранения заведется приложении - как правило это недешево

Сатана ещё шепчет такой вариант - пытаться записать в базу следующий - автоинкремент, если он занят - увеличивать значение на 1.

Времени на вставку не жалко, делаем ее для приложения фоновой. После 50 неудач считаем что ошибка.

есть много способов усложнить себе жизнь

всё станет слишком сложно если несколько мастеров, а шаг автоинкремента != 1

почему бы не задействовать старое нормальное решение для индексов - uuid?

а v1  кажись еще позволяет идентификатор ноды в адрес зашивать - если у вас проблема их отличать

uuidv6 ?

Музыкальная пауза в тему чата https://www.youtube.com/watch?v=lnDKs5tvEvQ

отвратительно

Так вот под чем пишут нечитаемый стабильный код

Всем привет, продолжаются мои похождения по миру ООП.

Вот есть паттерн репозиторий. Это абстракция над персистансом.

Пример условной задачи: есть набор сущностей, у них соответсвующие поля и связи. Возмем для примера.. Что там берут для примера всегда?

Возьмем Event, у него есть Country. Связь m2o.

Иногда хочется создать Event с Country вместе, а иногда — сначала Country, а затем Event.

Кто как считает:
— Должен ли репозиторий работать только с одной сущностью и не знать ничего про другие? Если да, то как быть тогда со связами?
— Данные какого формата из внутреннего слоя должен принимать репозиторий? DTO/POXO или обьекты БЛ?
— Какого формата во внешний слой должен возвращать репозиторий? DTO/POXO или сначала он должен воссаздать обьекты из данных персистанса и только затем передать во внутренний слой?

И в целом расскажите что вы думаете по поводу всего этого, что почитать куда сходить.

Исходная задача: инкапсулировать работу с персистансом за абстракцией, что бы не смешивать ее с БЛ во внутреннем слое.