id
Но его нет пока он не будет выдан базой. Какой должен быть id, когда я создаю сущность в сервисном слое, для последующего сохранения это entity в репозитории? Вопрос не конкретный а общий даже, в какую сторону читать
UUID
Если id == null, то репозиторий делает insert, если id != null, то репозиторий делает update.
Айди можно получить заранее и передать в сущность когда ее собираешь. Если база поддерживает секвенсы то можно сначала у нее запросить. Если нет то из удобных вариантов только uuid
В этом случае стэйт невалиден.
Например,в spring'е такая реализация репозитория: /* * @see org.springframework.data.repository.CrudRepository#save(java.lang.Object) */ public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else { return em.merge(entity); } } У entity есть атрибут isNew /** * @see org.springframework.data.domain.Persistable#isNew() */ public boolean isNew() { return null == getId(); } В этом случае стейт вполне валиден.
Эт понятно, гугли save your repositories from save
UUID - это выход. Но мне интересно. А если в базе ключами являются auto increment integer-ы? Вообще сущность без id - это нормальная ли практика? Ведь экземпляр сущности это что-то, что всегда отличается от другого экземпляра этой сущности, а если будут две несохраненные в базу сущности, то в коде невозможно будет их отличить, что противоречит правилам ООП. Неужели концепция incremental id не укладывается в ооп?
Autoicrement id это артифакт persistence слоя. В вашем домене вы как отличаете сущности друг от друга? Вот если бы все было в памяти, вы бы какой id выбрали?
Сущность по определению должна иметь идентити. Иначе это не сущность. Можно конечно по ссылкам все это разруливать если твои инструменты подобное поддерживают, но тут часто проблема что мы начинаем передавать повсюду саму сущность там где хватило бы ее айдишки увеличивая связанность без явной на то причины. Так же нюансы персистанса что мол айдишка появится только после комита транзакции может сильно повлиять на логику приложения. По сути у тебя персистанс протекает в систему. В некоторых кейсах это может и не быть проблемой
У автоинкрементов есть два варианта: - как в MySQL где значение получается при вставке. Тут вариантов нет - персистанс будет просачиваться - секвенсы где можно получить следующее значение вне транзакции - тут есть варианты мол мы можем перед операцией "создать что-то" запросить идентификатор и передавать его при создании экземпляра явно. Тогда все можно изолировать. То есть сторадж и что он поддерживает начинает влиять на подходы
Кажется не запрещено иметь локальный id и id из базы. Это если вдруг вам хочется взаимодействовать с объектом про который база ещё не знает - ну например ретраить его вставку в БД если что-то пошло не так. Это конечно так себе вариант и я сходу не могу придумать кейс в котором это бы перевесило минусы
Хороший вопрос, а что стоило бы использовать? Наверное тот же uuid, какие же ещё варианты, если других уникальных полей нет
я честно слабо представляю ситуацию при которой мы хотим юзать автоинкременты... ну то есть... есть какие-то определенные нюансы с тем что монотонно возрастающая последовательность эффективность и вот это все но все это слабо соотносится с "держать рядом еще один идентификатор". + там где реально от этого профит есть много вставок и возможно надо просто дизайн по другому делать
у uuid есть много вариантов, некоторые варианты сохраняют последовательность. Просто индекс жирнее
Обсуждают сегодня