streamalism.org

1. Oversikt

Dvalemodus 5 gir to forskjellige navngivningsstrategier for bruk med dvalemodusenheter: en implisitt navnestrategi og en fysisk navngivningsstrategi.

I denne opplæringen vil vi se hvordan du konfigurerer disse navngivningsstrategiene for å tilordne enheter til tilpassede tabell- og kolonnenavn.

For lesere som ikke er i dvale, må du sjekke innledningsartikkelen vår her.

2. Avhengigheter

Vi bruker den grunnleggende dvalemodusavhengigheten for denne opplæringen:

 org. dvale-dvalekjerne 5.3.6.Final 

3. Implisitt navnestrategi

Dvalemodus bruker et logisk navn for å kartlegge et enhets- eller attributtnavn til et tabell- eller kolonnenavn. Dette navnet kan tilpasses på to måter: det kan avledes automatisk ved å bruke en ImplicitNamingStrategy eller det kan defineres eksplisitt ved å bruke merknader.

De ImplicitNamingStrategy styrer hvordan dvalemodus får et logisk navn fra Java-klassen og eiendomsnavnene våre. Vi kan velge mellom fire innebygde strategier, eller vi kan lage våre egne.

For dette eksemplet bruker vi standardstrategien, ImplicitNamingStrategyJpaCompliantImpl. Ved å bruke denne strategien vil de logiske navnene være de samme som Java-klassen og eiendomsnavnene.

Hvis vi vil avvike fra denne strategien for en bestemt enhet, kan vi bruke merknader for å foreta disse tilpasningene. Vi kan bruke @Bord kommentar for å tilpasse navnet på en @Enhet. For en eiendom kan vi bruke @Kolonne kommentar:

@Entity @Table (name = "Kunder") offentlig klasse kunde {@Id @GeneratedValue privat Lang id; privat streng fornavn; privat streng etternavn; @Kolonne (navn = "e-post") privat streng e-postadresse; // getters og setters}

Ved hjelp av denne konfigurasjonen, logiske navn for Kunde enhet og dens egenskaper vil være:

Kunde -> Kunder fornavn -> fornavn etternavn -> etternavn e-postadresse -> e-post

4. Fysisk navngivningsstrategi

Nå som vi konfigurerte våre logiske navn, la oss ta en titt på de fysiske navnene våre.

Hibernate bruker Physical Naming Strategy for å kartlegge våre logiske navn til en SQL-tabell og dens kolonner.

Som standard vil det fysiske navnet være det samme som det logiske navnet som vi spesifiserte i forrige avsnitt. Hvis vi ønsker å tilpasse de fysiske navnene, kan vi lage en egendefinert PhysicalNamingStrategy klasse.

For eksempel kan det være lurt å bruke kamelnavnet i Java-koden vår, men vi ønsker å bruke understrekede atskilte navn for de faktiske tabell- og kolonnenavnene i databasen.

Nå kan vi bruke en kombinasjon av merknader og en skikk ImplicitNamingStrategy for å kartlegge disse navnene riktig, men Hibernate 5 gir PhysicalNamingStrategy som en måte å forenkle denne prosessen på. Det tar våre logiske navn fra forrige seksjon og lar oss tilpasse dem alle på ett sted.

La oss se hvordan dette gjøres.

Først lager vi en strategi som konverterer navnene på kameler til å bruke vårt mer vanlige 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 strengutskiftning = "$ 1_ $ 2"; final String newName = identifier.getText () .replaceAll (regex, erstatning) .toLowerCase (); returner Identifier.toIdentifier (newName); }}

Til slutt kan vi be Hibernate om å bruke vår nye strategi:

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

Ved å bruke vår nye strategi mot Kunde enhet, ville de fysiske navnene være:

Kunde -> kunders fornavn -> fornavn etternavn -> etternavn e-postadresse -> e-post

5. Konklusjon

I denne raske artikkelen har vi lært forholdet mellom implisitte og fysiske navngivningsstrategier.

Vi har også sett hvordan vi kan tilpasse de implisitte og fysiske navnene til en enhet og dens egenskaper.

Du kan se kildekoden for denne opplæringen på Github.