En guide til dvale-OGM

1. Oversigt

I denne vejledning gennemgår vi det grundlæggende i Hibernate Object / Grid Mapper (OGM).

Hibernate OGM leverer Java Persistence API (JPA) support til NoSQL-datalagre. NoSQL er et paraplyudtryk, der dækker en bred vifte af datalagring. For eksempel inkluderer dette nøgleværdi, dokument, kolonneorienteret og graforienteret datalager.

2. Arkitekturen i dvale OGM

Hibernate tilbyder traditionelt en Object Relational Mapping (ORM) motor til relationsdatabaser. Hibernate OGM-motor udvider sin funktionalitet til at understøtte NoSQL-datalagre. Den primære fordel ved at bruge den er konsistensen af JPA-grænsefladen på tværs af relationelle og NoSQL-datalagre.

Hibernate OGM er i stand til at levere abstraktion over et antal NoSQL-datalagre på grund af to nøglegrænseflader, DatastoreProvider og GridDialect. Derfor kommer hver nye NoSQL-datalager, som den understøtter, med en implementering af disse grænseflader.

Fra i dag understøtter det ikke alle NoSQL-datalagre, men det er i stand til at arbejde med mange af dem som Infinispan og Ehcache (nøgleværdi), MongoDB og CouchDB (dokument) og Neo4j (graf).

Det understøtter også fuldt ud transaktioner og kan arbejde med standard JTA-udbydere. For det første kan dette leveres gennem Jakarta EE-containeren uden nogen eksplicit konfiguration. Desuden kan vi bruge en enkeltstående JTA-transaktionshåndtering som Narayana i Java SE-miljøet.

3. Opsætning

Til denne vejledning bruger vi Maven til at trække de nødvendige afhængigheder til at arbejde med Hibernate OGM. Vi bruger også MongoDB.

For at afklare, lad os se, hvordan du opsætter dem til vejledningen.

3.1. Maven afhængigheder

Lad os se de afhængigheder, der kræves for at arbejde 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 trækker vi krævede afhængigheder gennem Maven:

Dvaletilstand OGM-dialekt til MongoDB
Narayana Transaction Manager (faktisk udbyder af JTA)

3.2. Persistence Unit

Det bliver vi også nødt til definer datalageroplysninger i dvale persistance.xml:

 org.hibernate.ogm.jpa.HibernateOgmPersistence

Bemærk de definitioner, vi har leveret her:

værdien af attributtransaktionstypen som "JTA" (dette indebærer, at vi ønsker en JTA-enhedsadministrator fra EntityManagerFactory)
udbyderen, hvilket er HibernateOgmPersistence til Hibernate OGM
et par yderligere detaljer relateret til DB (disse varierer typisk mellem forskellige datakilder)

Konfigurationen forudsætter, at MongoDB kører og er tilgængelig ved standardindstillinger. Hvis dette ikke er tilfældet, kan vi altid give oplysninger efter behov. En af vores tidligere artikler dækker også opsætning af MongoDB i detaljer.

4. Enhedsdefinition

Nu hvor vi har gennemgået det grundlæggende, lad os definere nogle enheder. Hvis vi har arbejdet med dvale ORM eller JPA før, har dette intet mere at tilføje. Dette er den grundlæggende forudsætning for Hibernate OGM. Det lover at lade os arbejde med forskellige NoSQL-datalagre med kun viden om JPA.

Til denne vejledning definerer vi en simpel objektmodel:

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

Lad os også definere dem i Java:

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

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

@Entity public class Editor {@Id @GeneratedValue (generator = "uuid") @GenericGenerator (name = "uuid", strategi = "uuid2") privat streng editorId; privat strengeditornavn; @OneToMany (mappedBy = "editor", cascade = CascadeType.PERSIST) privat sæt tildeltAuthors = nyt HashSet (); // konstruktører, getters og settere ...}

Vi har nu defineret enhedsklasser og kommenteret dem med JPA-standardkommentarer:

@Enhed at etablere dem som JPA-enheder
@Id at generere primære nøgler til enheder med UUID'er
@OneToMany og @ManyToOne at etablere tovejsforhold mellem enhederne

5. Operationer

Nu hvor vi har oprettet vores enheder, lad os se om vi kan udføre nogle operationer på dem. Som et første trin bliver vi nødt til at generere nogle testdata. Her opretter vi en Redaktør, nogle få Forfatter, og nogle Artikel. Vi etablerer også deres forhold.

Derefter, før vi kan udføre en operation, har vi brug for en forekomst af EntityManagerFactory. Vi kan bruge dette til at skabe EntityManager. Sammen med dette er vi nødt til at skabe TransactionManager til at håndtere transaktionsgrænser.

Lad os se, hvordan vi kan bruge disse til at fortsætte og hente de enheder, vi oprettede tidligere:

privat ugyldighed persistTestData (EntityManagerFactory entityManagerFactory, Editor-editor) kaster Undtagelse {TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager (); transactionManager.begin (); EntityManager entityManager = entityManagerFactory.createEntityManager (); entityManager.persist (editor); entityManager.close (); transactionManager.commit (); }

Her bruger vi EntityManager at fortsætte rodenheden, der kaskaderer til alle dens relationer. Vi udfører også denne operation inden for en defineret transaktionsgrænse.

Nu er vi klar til at indlæse den enhed, som vi lige har opretholdt, og kontrollere dens indhold. Vi kan køre en test for at bekræfte dette:

@Test offentlig ugyldighed givenMongoDB_WhenEntitiesCreated_thenCanBeRetrieved () kaster undtagelse {EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory ("ogm-mongodb"); Editor editor = createTestData (); persistTestData (entityManagerFactory, editor); 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åstande om at verificere enheder og relationer}

Her bruger vi EntityManager igen for at finde dataene og udføre standard påstande om det. Når vi kører denne test, genopretter den datalageret, vedvarer enhederne, henter dem tilbage og bekræfter.

Igen har vi det brugte bare JPA til at opretholde enhederne sammen med deres forhold. Tilsvarende vi bruger JPA til at indlæse enhederne tilbage og det hele fungerer fint, selv når vores databasevalg er MongoDB i stedet for en traditionel relationsdatabase.

6. Skift af backend

Vi kan også skifte vores backend. Lad os finde ud af nu, hvor svært det vil være at gøre dette.

Vi ændrer vores backend til Neo4j, som tilfældigvis er en populær graforienteret datalager.

Lad os først tilføje Maven-afhængighed for Neo4j:

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

Derefter bliver vi nødt til at tilføje den relevante persistensenhed i vores persistence.xml:

 org.hibernate.ogm.jpa.HibernateOgmPersistence

Kort sagt, dette er de meget grundlæggende konfigurationer, der kræves til Neo4j. Dette kan detaljeres yderligere efter behov.

Nå, det er stort set hvad der skal gøres. Når vi kører den samme test med Neo4j som backend-datalager, fungerer den ret problemfrit.

Bemærk, at vi har skiftet vores backend fra MongoDB, som tilfældigvis er en dokumentorienteret datalager, til Neo4j, som er en graforienteret datalager. Og vi gjorde alt dette med minimale ændringer og uden behov for ændringer i nogen af vores operationer.

7. Konklusion

I denne artikel har vi gennemgået det grundlæggende i Hibernate OGM, herunder dets arkitektur. Derefter implementerede vi en grundlæggende domænemodel og udførte forskellige operationer ved hjælp af forskellige DB'er.

Som altid er koden til eksemplerne tilgængelig på GitHub.

streamalism.org