Bevaringsspørsmål

I dag vil vi ha et nytt og superinteressant opplegg - ved å bruke Hibernate-funksjonene for å lagre klassehierarkiet i databasen.

Et klassehierarki er et sett med klasser knyttet til hverandre ved et arveforhold.

Tenk deg at du har tre klasser du vil lagre i databasen:

class User {
  int id;
  String name;
  LocalDate birthday;
}
class Employee extends User {
 	String occupation;
 	int salary;
 	LocalDate join;
}
class Client extends User {
   String address;
}

Klasser arves fra hverandre. Og det mest interessante er at du vil bruke Hibernate for å lagre objekter av disse klassene i databasen.

Løsningstyper

Hibernate har 4 mulige måter den kan knytte et klassehierarki til tabeller i en database:

  • Kartlagt Superklasse
  • enkelt bord
  • Sammenføyd Tabell
  • Tabell per klasse

Hver strategi antar sin egen tabellstruktur i databasen. Noen ganger er de ganske komplekse. Men spørsmål om HQL til dem er veldig enkle. Dette er akkurat tilfelle der fordelene med Hibernate er tydelig manifestert.

Jeg har aldri hørt disse begrepene oversatt til russisk, så jeg anbefaler også å uttale dem på engelsk.

Nedenfor vil vi analysere hva hver av dem betyr.

@MappedSuperClass

La oss starte med den enkleste løsningen - i databasen har du separate tabeller for hver klasse . For eksempel disse:

CREATE TABLE user {
  id INT,
  name VARCHAR,
  birthday DATE
}
CREATE TABLE employee {
  id INT,
  name VARCHAR,
  birthday DATE,
  occupation VARCHAR,
  salary INT,
  join DATE
}
CREATE TABLE client {
  id INT,
  name VARCHAR,
  birthday DATE,
  address VARCHAR
}

Bare du vet at klassene for disse tabellene er koblet sammen i et hierarki . Hvis du vil at Hibernate skal vite om dette også, må du legge til @MappedSuperclass- kommentaren til foreldreklassen . Uten det vil Hibernate ganske enkelt ignorere feltene og merknadene til den overordnede klassen.

Klasser med denne merknaden vil se slik ut:

@MappedSuperclass
class User {
  int id;
  String name;
  LocalDate birthday;
}
@Entity
class Employee extends User {
 	String occupation;
 	int salary;
 	LocalDate join;
}
@Entity
class Client extends User {
   String address;
}

Dette er den mest primitive måten å koble klassehierarkiet og databasen på. Denne tilnærmingen lar deg faktisk bare unngå dupliserte felt i klasser.

Databasespørringer i HQL vil bare returnere enheten hvis type er spesifisert eksplisitt. Du kan ikke skrive en databasespørring i HQL og få en liste over alle brukere: Bruker, Ansatt, Klient.