streamalism.org

1. Oversikt

I denne opplæringen vil vi gå gjennom det grunnleggende om Hibernate Object / Grid Mapper (OGM).

Hibernate OGM gir Java Persistence API (JPA) støtte for NoSQL datalagre. NoSQL er et paraplybegrep som dekker et bredt utvalg av datalagring. Dette inkluderer for eksempel nøkkelverdi, dokument, kolonneorientert og graforientert datalager.

2. Arkitekturen til dvalemodus OGM

Hibernate tilbyr tradisjonelt en Object Relational Mapping (ORM) -motor for relasjonsdatabaser. Hibernate OGM-motor utvider funksjonaliteten til å støtte NoSQL-datalagre. Den primære fordelen med å bruke den er konsistensen av JPA-grensesnittet på tvers av relasjonelle og NoSQL datalagre.

Hibernate OGM er i stand til å gi abstraksjon over et antall NoSQL-datalagre på grunn av to viktige grensesnitt, DatastoreProvider og GridDialect. Derfor kommer hver nye NoSQL-datalagring som den støtter med en implementering av disse grensesnittene.

Per i dag støtter den ikke alle NoSQL-datalagre, men den er i stand til å jobbe med mange av dem som Infinispan og Ehcache (nøkkelverdi), MongoDB og CouchDB (dokument) og Neo4j (graf).

Den støtter også fullt ut transaksjoner og kan samarbeide med standard JTA-leverandører. For det første kan dette leveres gjennom Jakarta EE-containeren uten noen eksplisitt konfigurasjon. Videre kan vi bruke en frittstående JTA-transaksjonsbehandling som Narayana i Java SE-miljøet.

3. Oppsett

For denne opplæringen bruker vi Maven til å trekke de nødvendige avhengighetene for å jobbe med Hibernate OGM. Vi bruker også MongoDB.

For å avklare, la oss se hvordan du konfigurerer dem for opplæringen.

3.1. Maven avhengigheter

La oss se avhengighetene som kreves for å jobbe med Hibernate OGM og MongoDB:

 org.hibernate.ogm hibernate-ogm-mongodb 5.4.0.Final org.jboss.narayana.jta narayana-jta 5.9.2.Final 

Her trekker vi nødvendige avhengigheter gjennom Maven:

• Dvalemodus OGM-dialekt for MongoDB
• Narayana Transaction Manager (faktisk leverandør av JTA)

3.2. Persistence Unit

Vi må også definere datalagringsdetaljer i dvale persistance.xml:

 org.hibernate.ogm.jpa.HibernateOgmPersistence 

Legg merke til definisjonene vi har gitt her:

• verdien av attributtransaksjonstypen som "JTA" (dette innebærer at vi vil ha en JTA-enhetsleder fra EntityManagerFactory)
• leverandøren, som er HibernateOgmPersistence for Hibernate OGM
• noen flere detaljer knyttet til DB (disse varierer vanligvis mellom forskjellige datakilder)

Konfigurasjonen forutsetter at MongoDB kjører og er tilgjengelig på standardinnstillinger. Hvis dette ikke er tilfelle, kan vi alltid gi detaljer etter behov. En av våre tidligere artikler dekker også oppsett av MongoDB i detalj.

4. Enhetsdefinisjon

Nå som vi har gått gjennom det grunnleggende, la oss definere noen enheter. Hvis vi jobbet med Hibernate ORM eller JPA før, har dette ikke noe mer å legge til. Dette er den grunnleggende forutsetningen for dvalemodus OGM. Den lover å la oss jobbe med forskjellige NoSQL-datalagre med bare kunnskapen om JPA.

For denne opplæringen vil vi definere en enkel objektmodell:

Det definerer Artikkel, Forfatter og Redaktør klasser sammen med deres forhold.

La oss også definere dem i Java:

@Entity public class Article {@Id @GeneratedValue (generator = "uuid") @GenericGenerator (name = "uuid", strategi = "uuid2") privat streng ArticleId; privat strengartikkelTittel; @ManyToOne privat forfatterforfatter; // konstruktører, getters og settere ...}

@Entity public class Forfatter {@Id @GeneratedValue (generator = "uuid") @GenericGenerator (name = "uuid", strategi = "uuid2") privat streng authorId; private String authorName; @ManyToOne redaktør for privatredaktør; @OneToMany (mappedBy = "author", cascade = CascadeType.PERSIST) private Set authoredArticles = new HashSet (); // konstruktører, getters og settere ...}

@Entity public class Editor {@Id @GeneratedValue (generator = "uuid") @GenericGenerator (name = "uuid", strategi = "uuid2") privat streng editorId; privat strengredigeringsnavn; @OneToMany (mappedBy = "redaktør", cascade = CascadeType.PERSIST) privat sett allocAuthors = ny HashSet (); // konstruktører, getters og settere ...}

Vi har nå definert enhetsklasser og kommentert dem med JPA-standardkommentarer:

• @Enhet å etablere dem som JPA-enheter
• @Id for å generere primærnøkler for enhetene med UUID-er
• @OneToMany og @ManyToOne å etablere toveis forhold mellom enhetene

5. Operasjoner

Nå som vi har opprettet enhetene våre, la oss se om vi kan utføre noen operasjoner på dem. Som et første trinn må vi generere noen testdata. Her oppretter vi en Redaktør, Noen Forfatter, og noe Artikkel. Vi vil også etablere deres forhold.

Deretter, før vi kan utføre noen operasjon, trenger vi en forekomst av EntityManagerFactory. Vi kan bruke dette til å lage EntityManager. Sammen med dette trenger vi å skape TransactionManager å håndtere transaksjonsgrenser.

La oss se hvordan vi kan bruke disse til å vedvare og hente enhetene vi opprettet tidligere:

privat tomrom persistTestData (EntityManagerFactory entityManagerFactory, Editor editor) kaster Unntak {TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager (); transactionManager.begin (); EntityManager entityManager = entityManagerFactory.createEntityManager (); entityManager.persist (redaktør); entityManager.close (); transactionManager.commit (); }

Her bruker vi EntityManager å vedvare rotenheten, som faller inn i alle dens forhold. Vi utfører også denne operasjonen innenfor en definert transaksjonsgrense.

Nå er vi klare til å laste inn enheten som vi nettopp vedvarte og bekrefte innholdet. Vi kan kjøre en test for å bekrefte dette:

@Test offentlig ugyldighet givenMongoDB_WhenEntitiesCreated_thenCanBeRetrieved () kaster Unntak {EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory ("ogm-mongodb"); Editor editor = createTestData (); persistTestData (entityManagerFactory, redaktør); TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager (); transactionManager.begin (); EntityManager entityManager = entityManagerFactory.createEntityManager (); Editor loadedEditor = entityManager.find (Editor.class, editor.getEditorId ()); assertThat (loadedEditor) .isNotNull (); // Andre påstander om å verifisere enhetene og relasjonene}

Her bruker vi EntityManager igjen for å finne dataene og utføre standard påstander om det. Når vi kjører denne testen, starter den datalagringen, vedvarer enhetene, henter dem tilbake og verifiserer.

Igjen, vi har brukte nettopp JPA til å vedvare enhetene sammen med forholdet deres. På samme måte, vi bruker JPA for å laste enhetene tilbake og alt fungerer bra, selv når vårt databasevalg er MongoDB i stedet for en tradisjonell relasjonsdatabase.

6. Bytte bakside

Vi kan også bytte backend. La oss finne ut hvor vanskelig det vil være å gjøre dette.

Vi endrer backend til Neo4j, som tilfeldigvis er en populær graforientert datalager.

For det første, la oss legge til Maven-avhengigheten for Neo4j:

 org.hibernate.ogm dvalemodus-ogm-neo4j 5.4.0.Final 

Deretter må vi legge til den aktuelle utholdenhetsenheten i vår persistence.xml:

 org.hibernate.ogm.jpa.HibernateOgmPersistence 

Kort sagt, dette er de helt grunnleggende konfigurasjonene som kreves for Neo4j. Dette kan bli nærmere beskrevet etter behov.

Vel, det er ganske mye det som må gjøres. Når vi kjører den samme testen med Neo4j som backend-datalagringen, fungerer den ganske sømløst.

Merk at vi har byttet backend fra MongoDB, som tilfeldigvis er en dokumentorientert datalager, til Neo4j, som er en graforientert datalager. Og vi gjorde alt dette med minimale endringer og uten behov for endringer i noen av våre operasjoner.

7. Konklusjon

I denne artikkelen har vi gått gjennom det grunnleggende om Hibernate OGM, inkludert arkitekturen. Deretter implementerte vi en grunnleggende domenemodell og utførte forskjellige operasjoner ved hjelp av forskjellige DB-er.

Som alltid er koden for eksemplene tilgjengelig på GitHub.