Equals i hashCode oparte o UUID

Equals i hashCode oparte o UUID
XO
  • Rejestracja:ponad 4 lata
  • Ostatnio:ponad 3 lata
  • Lokalizacja:Gdańsk
  • Postów:27
0

Pod spodem Hibernate i Spring.

Mam taką encję bazodanową:

Kopiuj
@Entity
@Table(name = "users")
public class User {

  @Id
  private final UUID id = UUID.randomUUID();

  private String name;

  // .. etc.
}

UUID jest nigdy nullem.

Jak będzie wyglądała implementacja equals i hashcode zgodnie ze sztuką? A co jeśli User byłby final?

crejk
  • Rejestracja:ponad 6 lat
  • Ostatnio:około 15 godzin
  • Postów:46
0

Nie rozumiem połowy z tego co napisałeś, ale jeśli chcesz equals i hashaCode oparte tylko na uuid, to po prostu wygeneruj je zaznaczając tylko pole id?
Poza tym ani pole ani klasa nie może być finalna.

XO
  • Rejestracja:ponad 4 lata
  • Ostatnio:ponad 3 lata
  • Lokalizacja:Gdańsk
  • Postów:27
0

Dlaczego pole nie może być finalne?

Kopiuj
public interface UserRepository extends CrudRepository<User, UUID> {
  Optional<User> findBySomething(Something something);
}

Zwraca mi usera o takim samym uuid jak przy tworzeniu.

edytowany 1x, ostatnio: Xorxorxor
SL
  • Rejestracja:około 7 lat
  • Ostatnio:około 7 godzin
  • Postów:900
1

@Xorxorxor: pytanie jest tak naprawdę biznesowe. Co ma się stać, jak w dwóch zapytaniach zapytasz się o tego same usera a dostaniesz inne nazwiska? User jest niemutowalny a jednak mamy różne wartości. Czy wtedy mamy do czynienia z tym samym userem czy innym? Java i inne języki bardzo spłycają koncept "bycia równym czemuś", dla bezpieczeństwa użyłbym wszystkich pól a samego sprawdzania UUID tylko w sytuacjach, gdzie jesteśmy pewni np. wszyscy userzy pochodzą z tego samego zapytania

JM
  • Rejestracja:ponad 3 lata
  • Ostatnio:około 3 lata
  • Postów:93
0
Xorxorxor napisał(a):

Dlaczego pole nie może być finalne?

Ukochane hibernate tak wymaga

XO
A przykład wyżej działa...
jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 11 godzin
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4708
0
J.Muzykant napisał(a):

Ukochane hibernate tak wymaga

Nieprawda. Co więcej najwięcej durnych ograniczeń nakłada specyfikacja JPA, a nie sam hibernate.
Ale pole finalne jest ok. Trzeba za to mieć bezparametrowy konstruktor (dramat), ale można go mieć protected (chociaż tyle).


jeden i pół terabajta powinno wystarczyć każdemu

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.