UUID jako dodatkowe pole w encji a DTO.

Ja bym na twoim miejscu zrobił dwie klasy DTO, jedną do zapisu która nie miała by UUID'a bo ten byłby generowany po stronie serwera bezpośrednio w encji, i drugą do aktualizacji która miałaby ten UUID i dodał settera / ustawiał przez konstruktor / mapper. Ewentualnie nic nie stoi na przeszkodzie aby generować nowy UUID przy aktualizacji i tak będziesz miał ID jako zachowanie ciągłości tożsamości rekordu.

@MrMadMatt: generowanie za każdym razem nowego UUID raczej jest słabym pomysłem, założeniem tutaj jest żeby był przez cały czas niezmienny.
Podejście z DTO w którym ustawiam UUID podczas edycji też raczej jest zbędne ponieważ nie będę aktualizował tego pola podczas updatów, mam ustawione w column updatable na false.
Bardziej chodzi mi o te equals i hashCode czy ma to w ogóle sens? Czy nie przeciążać tych metod. W zasadzie DTO powinny służyć tylko do wyświetlania danych, ale w tym przypadku przenoszą dane jakie mają zostać zapisane bądź zedytowane.

Może ktoś inny z bardziej doświadczonych osób jest mi w stanie wyjaśnić jakie jest najlepsze podejście? @Shalom @jarekr000000

Nie wiem dokładnie co próbujesz zrobić, ale UUID możesz przecież mieć w ścieżce endpointu i zresztą zwykle tak się robi, tzn jakieś /edit/1234-dupa a nie /edit/ i w payloadzie ID. Ale to jest moim zdaniem szczegół i zawracasz sobie głowę duperelami. Zrób tak żeby było ci wygodnie.

A po co ci te UUID? W kontekście bazy danych ja nie widzę różnicy w funkcjonalności między UUID a zwykłym id. UUID przydałoby ci się jakbyś robił porównywanie encji zanim ją spersystujesz i baza wygeneruje dla niej unikalne id.

Moja rada: wywal z tego projektu hibernate/jpa albo ewentualnie W OGÓLE nie posługuj się NIGDZIE w aplikacji tymi @Entity DTOsami. Wyciągnij co chcesz z bazy, przemapuj od razu na jakieś obiekty domenowe i voila. Analogicznie w drugą stronę, mapuj na te entity tylko przed samym zapisem do bazy. Nagle wszelkie problemy znikają jak ręką odjął. Bo teraz to wygląda na klasyczne dzielne walczenie z problemami nie znanymi w innych technologiach ;]

@MrMadMatt:
W CRUDzie taka sytuacja raczej nie powinna mieć sytuacja. A problem OP by nie istniał w ogóle, gdyby w takiej sytuacji nie operował na encjach JPA w logice biznesowej, a na zwykłych domenowych klasach javowych. Wtedy generowanie UUID jak i operacje na mapach, czy czymkolwiek innym, odbywałoby się poza flow JPA. No ale wracamy do kwestii tego, że to CRUD - tu nie ma logiki więc imo użycie UUID to sztuka dla sztuki.

Chyba zostałem źle zrozumiany ponieważ ja nigdzie nie korzystam z Entity jak z obiektów biznesowych. Po pobraniu z dao są one od razu mapowane na obiekty. W moim przypadku od razu na to DTO ponieważ jest to prosta aplikacja typu CRUD.

Mam swoje entity usera, które jest mapowane na DTO i odwrotnie. Przy tworzeniu obiektu mam po prostu DTO, który odbieram w controllerze a następnie waliduje, jeśli walidacja przejdzie pomyślnie to mapuje to na Encje i zapisuje. Żadnej logiki nie robię na encji.
Przy pobieraniu obiektu do edycji albo listy po prostu w serwisie pobieram z dao encje i mapuje na DTO, które przesyłam na front.

Mój endpoint do edycji nie wygląda w stylu edit/ i w payloadzie ID tylko jest to edit/{id}

I tutaj moje pytanie czy te DTO powinny być odpowiedzialne za tworzenie unikalnego UUID i czy jest sens umieszczać to UUID w DTOsach jeśli w zasadzie służy on do transportu danych. I czy takie DTO powinno mieć przeciążane equals i hascode z użyciem UUID tak jak encja?

Generalnie zrozumiałbym gdyby ktoś generował sobie jakiegoś uida zamiast idka numerycznego, żeby mieć identyfikator encji zanim zostanie on zapisany do bazy (i ktoś miałby ku temu powód). Generalnie dawno nie pracowałem z hibernatem i nie rozumiem czemu ID nie mógłby byc w hashcodzie?

I tutaj moje pytanie czy te DTO powinny być odpowiedzialne za tworzenie unikalnego UUID i czy jest sens umieszczać to UUID w DTOsach jeśli w zasadzie służy on do transportu danych. I czy takie DTO powinno mieć przeciążane equals i hascode z użyciem UUID tak jak encja?

Ale po co? Generalnie hashcode i equals mozesz miec na podstawie ID i typu, jeżeli będziesz chciał porównywać DTOsy (których używasz zamiast obiektów domenowych, bo masz prosta apke) to porównujesz je w taki sam sposób, w większosci przypadków to wlasnie identyfikator obiektu odroznia go od innych obiektów np 2 osoby mogą miec tak samo na imie i nazwisko, ale to są rózne osoby, z pominięciem sytuacji w których obiekt posiada jakiś klucz naturalny, np numer VIN dla samochodu lub kilka własciwosci obiektów będzie dany obiekt identyfikować. Co do pytania czy equals i hashcode taki sam jak w encji - generalnie tak, w końcu te 2 obiekty (DTO i encja) reprezentują ten sam byt, tylko uzywasz ich w różnych warstwach aplikacji żeby oddzielić od siebie abstrakcje

hcubyc napisał(a):

Generalnie zrozumiałbym gdyby ktoś generował sobie jakiegoś uida zamiast idka numerycznego, żeby mieć identyfikator encji zanim zostanie on zapisany do bazy (i ktoś miałby ku temu powód). Generalnie dawno nie pracowałem z hibernatem i nie rozumiem czemu ID nie mógłby byc w hashcodzie?

Chodzi o np. nowo utworzone encje, które nie mają jeszcze id bo nie nadajemy sami id tylko mamy ustawione @GeneratedValue w encji i baza za nas to robi. Przykładowo mamy jakąś encję, która ma w sobie relacje i przechowuje je w secie, to jak wtedy dodamy kilka nowo utworzonych encji bez id, które mają equals i hashcode na bazie id?

No to możesz generować UUID dla takich encji, który będzie jednocześnie ich ID. Przy czym nie musi być to zwykły UUID, jest wiele libek, które pozwalają generować unikalne (do pewnego stopnia) IDki a'la youtube.

Przykładowo mamy jakąś encję, która ma w sobie relacje i przechowuje je w secie, to jak wtedy dodamy kilka nowo utworzonych encji bez id, które mają equals i hashcode na bazie id?

Porównywać na podstawie domyslnego hashcoda i equalsa jeżeli nie ma ID? Lub jeżeli encja ma taką możliwość to na podstawie zbioru własciwosci obiektu (np. e-mail jest unikalny, wiec mozesz porownac uzytkownikow na podstawie e-maila).
Generalnie pomysł z UUIDem nie jest zły, ale opędza tylko jeden przypadek, a i tak musiałbyś kopiować (albo miec jakas super klase) te metode dla każdej klasy, więc jak dla mnie to srednie rozwiazanie problemu. Inna sprawa to pytanie czy przypadek pozwala żeby najpierw zapisac obiekty do bazy, a pozniej ustawic im relacje?