streamalism.org

1. Oversigt

Hibernate 5 giver to forskellige navngivningsstrategier til brug med dvaleenheder: en implicit navngivningsstrategi og en fysisk navngivningsstrategi.

I denne vejledning ser vi, hvordan man konfigurerer disse navngivningsstrategier til at kortlægge enheder til tilpassede tabel- og kolonnenavne.

For læsere, der er nye i dvale, skal du tjekke vores introduktionsartikel her.

2. Afhængigheder

Vi bruger den grundlæggende dvale-kerneafhængighed til denne vejledning:

 org. dvale-dvale-core 5.3.6.Final 

3. Implicit navngivningsstrategi

Dvaletilstand bruger et logisk navn til at kortlægge en enhed eller et attributnavn til et tabel- eller kolonnenavn. Dette navn kan tilpasses på to måder: det kan afledes automatisk ved hjælp af en ImplicitNamingStrategy eller det kan defineres eksplicit ved hjælp af annoteringer.

Det ImplicitNamingStrategy styrer, hvordan dvale udleder et logisk navn fra vores Java-klasse og ejendomsnavne. Vi kan vælge mellem fire indbyggede strategier, eller vi kan oprette vores egne.

I dette eksempel bruger vi standardstrategien, ImplicitNamingStrategyJpaCompliantImpl. Ved hjælp af denne strategi vil de logiske navne være de samme som vores Java-klasse og ejendomsnavne.

Hvis vi ønsker at afvige fra denne strategi for en bestemt enhed, kan vi bruge kommentarer til at foretage disse tilpasninger. Vi kan bruge @Bord kommentar for at tilpasse navnet på en @Enhed. For en ejendom kan vi bruge @Kolonne kommentar:

@Entity @Table (name = "Kunder") offentlig klasse kunde {@Id @GeneratedValue privat Lang id; privat streng fornavn; privat streng efternavn; @Column (name = "email") privat String emailAddress; // getters og setters}

Ved hjælp af denne konfiguration logiske navne til Kunde enhed og dens egenskaber ville være:

Kunde -> Kunder fornavn -> fornavn efternavn -> efternavn e-mailadresse -> e-mail

4. Fysisk navngivningsstrategi

Nu hvor vi konfigurerede vores logiske navne, lad os se på vores fysiske navne.

Dvaletilstand bruger den fysiske navngivningsstrategi til at kortlægge vores logiske navne til en SQL-tabel og dens kolonner.

Som standard vil det fysiske navn være det samme som det logiske navn som vi specificerede i det foregående afsnit. Hvis vi vil tilpasse de fysiske navne, kan vi oprette en brugerdefineret PhysicalNamingStrategy klasse.

For eksempel vil vi måske bruge kamelnavne i vores Java-kode, men vi vil bruge understregede separate navne til vores aktuelle tabel- og kolonnenavne i databasen.

Nu kunne vi bruge en kombination af annoteringer og en brugerdefineret ImplicitNamingStrategy for at kortlægge disse navne korrekt, men Hibernate 5 giver PhysicalNamingStrategy som en måde at forenkle denne proces på. Det tager vores logiske navne fra det foregående afsnit og giver os mulighed for at tilpasse dem alle ét sted.

Lad os se, hvordan dette gøres.

Først opretter vi en strategi, der konverterer vores kamelnavne til at bruge vores mere standard SQL-format:

offentlig klasse CustomPhysicalNamingStrategy implementerer PhysicalNamingStrategy {@Override public Identifier toPhysicalCatalogName (final Identifier identifier, final JdbcEnvironment jdbcEnv) {return convertToSnakeCase (identifier); } @ Override public Identifier toPhysicalColumnName (final Identifier identifier, final JdbcEnvironment jdbcEnv) {return convertToSnakeCase (identifier); } @ Override public Identifier toPhysicalSchemaName (final Identifier identifier, final JdbcEnvironment jdbcEnv) {return convertToSnakeCase (identifier); } @ Override public Identifier toPhysicalSequenceName (final Identifier identifier, final JdbcEnvironment jdbcEnv) {return convertToSnakeCase (identifier); } @ Override public Identifier toPhysicalTableName (final Identifier identifier, final JdbcEnvironment jdbcEnv) {return convertToSnakeCase (identifier); } private Identifier convertToSnakeCase (final Identifier identifier) ​​{final String regex = "([a-z]) ([A-Z])"; endelig udskiftning af streng = "$ 1_ $ 2"; final String newName = identifier.getText () .replaceAll (regex, erstatning) .toLowerCase (); returner Identifier.toIdentifier (newName); }}

Endelig kan vi bede Hibernate om at bruge vores nye strategi:

hibernate.physical_naming_strategy = com.baeldung.hibernate.namingstrategy.CustomPhysicalNamingStrategy

Brug af vores nye strategi mod Kunde enhed, ville de fysiske navne være:

Kunde -> kunders fornavn -> fornavn efternavn -> efternavn e-mailadresse -> e-mail

5. Konklusion

I denne hurtige artikel har vi lært forholdet mellem de implicitte og fysiske navngivningsstrategier.

Vi har også set, hvordan man tilpasser de implicitte og fysiske navne på en enhed og dens egenskaber.

Du kan se kildekoden til denne tutorial på Github.