Pod spodem Hibernate i Spring.
Mam taką encję bazodanową:
@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?
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.
Dlaczego pole nie może być finalne?
public interface UserRepository extends CrudRepository<User, UUID> {
Optional<User> findBySomething(Something something);
}
Zwraca mi usera o takim samym uuid jak przy tworzeniu.
@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
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).