Skip to content

Commit e4539d9

Browse files
committed
quit using abbreviations
don't know quite what came over me...
1 parent 6078e47 commit e4539d9

File tree

4 files changed

+94
-94
lines changed

4 files changed

+94
-94
lines changed

documentation/src/main/asciidoc/introduction/Configuration.adoc

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -173,15 +173,15 @@ We may obtain an `EntityManagerFactory` by calling `Persistence.createEntityMana
173173

174174
[source,java]
175175
----
176-
EntityManagerFactory emf =
176+
EntityManagerFactory entityManagerFactory =
177177
Persistence.createEntityManagerFactory("org.hibernate.example");
178178
----
179179

180180
If necessary, we may override configuration properties specified in `persistence.xml`:
181181

182182
[source,java]
183183
----
184-
EntityManagerFactory emf =
184+
EntityManagerFactory entityManagerFactory =
185185
Persistence.createEntityManagerFactory("org.hibernate.example",
186186
Map.of(AvailableSettings.JAKARTA_JDBC_PASSWORD, password));
187187
----
@@ -193,7 +193,7 @@ Alternatively, the venerable class `org.hibernate.cfg.Configuration` allows an i
193193

194194
[source,java]
195195
----
196-
SessionFactory sf = new Configuration()
196+
SessionFactory sessionFactory = new Configuration()
197197
.addAnnotatedClass(Book.class)
198198
.addAnnotatedClass(Author.class)
199199
.setProperty(AvailableSettings.JAKARTA_JDBC_URL, "jdbc:postgresql://localhost/example")
@@ -228,7 +228,6 @@ Of course, we're not going to cover every useful configuration setting in this c
228228
Instead, we'll mention the ones you need to get started, and come back to some other important settings later, especially when we talk about performance tuning.
229229

230230
[TIP]
231-
// .Ya ain't gunna need 'em
232231
====
233232
Hibernate has many—too many—switches and toggles.
234233
Please don't go crazy messing about with these settings; most of them are rarely needed, and many only exist to provide backward compatibility with older versions of Hibernate.

documentation/src/main/asciidoc/introduction/Interacting.adoc

Lines changed: 62 additions & 61 deletions
Original file line numberDiff line numberDiff line change
@@ -91,28 +91,28 @@ It's quite unsurprising that we may use this object to create an `EntityManager`
9191

9292
[source,java]
9393
----
94-
EntityManager em = emf.createEntityManager();
94+
EntityManager entityManager = entityManagerFactory.createEntityManager();
9595
----
9696

9797
When we're finished with the `EntityManager`, we should explicitly clean it up:
9898

9999
[source,java]
100100
----
101-
em.close();
101+
entityManager.close();
102102
----
103103

104104
On the other hand, if we're starting from a `SessionFactory`, as described in <<configuration-api>>, we may use:
105105

106106
[source,java]
107107
----
108-
Session s = sf.openSession();
108+
Session session = sessionFactory.openSession();
109109
----
110110

111111
But we still need to clean up:
112112

113113
[source,java]
114114
----
115-
em.close();
115+
entityManager.close();
116116
----
117117

118118
.Injecting the `EntityManager`
@@ -122,14 +122,14 @@ For example, in Java (or Jakarta) EE you would write:
122122
123123
[source,java]
124124
----
125-
@PersistenceContext EntityManager em;
125+
@PersistenceContext EntityManager entityManager;
126126
----
127127
128128
In Quarkus, injection is handled by CDI:
129129
130130
[source,java]
131131
----
132-
@Inject EntityManager em;
132+
@Inject EntityManager entityManager;
133133
----
134134
****
135135

@@ -143,8 +143,8 @@ The idiom we recommend is the following:
143143

144144
[source,java]
145145
----
146-
EntityManager em = emf.createEntityManager();
147-
EntityTransaction tx = em.getTransaction();
146+
EntityManager entityManager = entityManagerFactory.createEntityManager();
147+
EntityTransaction tx = entityManager.getTransaction();
148148
try {
149149
tx.begin();
150150
//do some work
@@ -156,17 +156,17 @@ catch (Exception e) {
156156
throw e;
157157
}
158158
finally {
159-
em.close();
159+
entityManager.close();
160160
}
161161
----
162162

163163
Using Hibernate's native APIs we might write something really similar,
164164
// [source,java]
165165
// ----
166-
// Session s = sf.openSession();
166+
// Session session = sessionFactory.openSession();
167167
// Transaction tx = null;
168168
// try {
169-
// tx = s.beginTransaction();
169+
// tx = session.beginTransaction();
170170
// //do some work
171171
// ...
172172
// tx.commit();
@@ -176,14 +176,14 @@ Using Hibernate's native APIs we might write something really similar,
176176
// throw e;
177177
// }
178178
// finally {
179-
// s.close();
179+
// session.close();
180180
// }
181181
// ----
182182
but since this sort of code is extremely tedious, we have a much nicer option:
183183

184184
[source,java]
185185
----
186-
sf.inTransaction(s -> {
186+
sessionFactory.inTransaction(session -> {
187187
//do the work
188188
...
189189
});
@@ -347,14 +347,14 @@ For example, to disable flushes that occur before query execution, call:
347347

348348
[source,java]
349349
----
350-
em.setFlushMode(FlushModeType.COMMIT);
350+
entityManager.setFlushMode(FlushModeType.COMMIT);
351351
----
352352

353353
Hibernate allows greater control over the flush mode than JPA:
354354

355355
[source,java]
356356
----
357-
s.setHibernateFlushMode(FlushMode.MANUAL);
357+
session.setHibernateFlushMode(FlushMode.MANUAL);
358358
----
359359

360360
Since flushing is a somewhat expensive operation (the session must dirty-check every entity in the persistence context), setting the flush mode to `COMMIT` can occasionally be a useful optimization.
@@ -420,19 +420,19 @@ So for the `Session` API we would write:
420420
[source,java]
421421
----
422422
List<Book> matchingBooks =
423-
s.createSelectionQuery("from Book where title like :titleSearchPattern", Book.class)
424-
.setParameter("titleSearchPattern", titleSearchPattern)
425-
.getResultList();
423+
session.createSelectionQuery("from Book where title like :titleSearchPattern", Book.class)
424+
.setParameter("titleSearchPattern", titleSearchPattern)
425+
.getResultList();
426426
----
427427

428428
Or, if we're sticking to the JPA-standard APIs:
429429

430430
[source,java]
431431
----
432432
List<Book> matchingBooks =
433-
s.createQuery("from Book where title like :titleSearchPattern", Book.class)
434-
.setParameter("titleSearchPattern", titleSearchPattern)
435-
.getResultList();
433+
session.createQuery("from Book where title like :titleSearchPattern", Book.class)
434+
.setParameter("titleSearchPattern", titleSearchPattern)
435+
.getResultList();
436436
----
437437

438438
The only difference between `createSelectionQuery()` and `createQuery()` is that `createSelectionQuery()` throw an exception if passed a Mutation.
@@ -444,9 +444,9 @@ These are called _ordinal parameters_.
444444
[source,java]
445445
----
446446
List<Book> matchingBooks =
447-
s.createSelectionQuery("from Book where title like ?1", Book.class)
448-
.setParameter(1, titleSearchPattern)
449-
.getResultList();
447+
session.createSelectionQuery("from Book where title like ?1", Book.class)
448+
.setParameter(1, titleSearchPattern)
449+
.getResultList();
450450
----
451451

452452
When a query has multiple parameters, named parameters tend to be easier to read, even if slightly more verbose.
@@ -463,19 +463,19 @@ If we're expecting a query to return a single result, we can use `getSingleResul
463463
[source,java]
464464
----
465465
Book book =
466-
s.createSelectionQuery("from Book where isbn = ?1", Book.class)
467-
.setParameter(1, isbn)
468-
.getSingleResult();
466+
session.createSelectionQuery("from Book where isbn = ?1", Book.class)
467+
.setParameter(1, isbn)
468+
.getSingleResult();
469469
----
470470

471471
Or, if we're expecting it to return at most one result, we can use `getSingleResultOrNull()`.
472472

473473
[source,java]
474474
----
475475
Book bookOrNull =
476-
s.createSelectionQuery("from Book where isbn = ?1", Book.class)
477-
.setParameter(1, isbn)
478-
.getSingleResultOrNull();
476+
session.createSelectionQuery("from Book where isbn = ?1", Book.class)
477+
.setParameter(1, isbn)
478+
.getSingleResultOrNull();
479479
----
480480

481481
The difference, of course, is that `getSingleResult()` throws an exception if there is no matching row in the database, whereas `getSingleResultOrNull()` just returns `null`.
@@ -488,10 +488,10 @@ To disable this behavior, set the flush mode to `COMMIT` or `MANUAL`:
488488
[source,java]
489489
----
490490
Book bookOrNull =
491-
s.createSelectionQuery("from Book where isbn = ?1", Book.class)
492-
.setParameter(1, isbn)
493-
.setHibernateFlushMode(MANUAL)
494-
.getSingleResult();
491+
session.createSelectionQuery("from Book where isbn = ?1", Book.class)
492+
.setParameter(1, isbn)
493+
.setHibernateFlushMode(MANUAL)
494+
.getSingleResult();
495495
----
496496

497497
[CAUTION]
@@ -520,14 +520,14 @@ Using the JPA-standard APIs, this would be a `CriteriaBuilder`, and we get it fr
520520

521521
[source,java]
522522
----
523-
CriteriaBuilder cb = emf.getCriteriaBuilder();
523+
CriteriaBuilder cb = entityManagerFactory.getCriteriaBuilder();
524524
----
525525

526526
But if we have a `SessionFactory`, we get something much better, a `HibernateCriteriaBuilder`:
527527

528528
[source,java]
529529
----
530-
HibernateCriteriaBuilder cb = sf.getCriteriaBuilder();
530+
HibernateCriteriaBuilder cb = sessionFactory.getCriteriaBuilder();
531531
----
532532

533533
The `HibernateCriteriaBuilder` extends `CriteriaBuilder` and adds many operations that JPQL doesn't have.
@@ -540,14 +540,14 @@ Either:
540540
541541
[source,java]
542542
----
543-
HibernateCriteriaBuilder cb = emf.unwrap(SessionFactory.class).getCriteriaBuilder();
543+
HibernateCriteriaBuilder cb = entityManagerFactory.unwrap(SessionFactory.class).getCriteriaBuilder();
544544
----
545545
546546
Or simply:
547547
548548
[source,java]
549549
----
550-
HibernateCriteriaBuilder cb = (HibernateCriteriaBuilder) emf.getCriteriaBuilder();
550+
HibernateCriteriaBuilder cb = (HibernateCriteriaBuilder) entityManagerFactory.getCriteriaBuilder();
551551
----
552552
====
553553

@@ -600,8 +600,8 @@ For example:
600600
[source,java]
601601
----
602602
List<Book> matchingBooks =
603-
s.createSelectionQuery(query)
604-
.getResultList();
603+
session.createSelectionQuery(query)
604+
.getResultList();
605605
----
606606

607607
When all else fails, and sometimes even before that, we're left with the option of writing a query in SQL.
@@ -627,9 +627,9 @@ For the most simple cases, Hibernate can infer the shape of the result set:
627627

628628
[source, java]
629629
----
630-
Book book = s.createNativeQuery("select * from Books where isbn = ?1", Book.class).getSingleResult();
630+
Book book = session.createNativeQuery("select * from Books where isbn = ?1", Book.class).getSingleResult();
631631
632-
String title = s.createNativeQuery("select title from Books where isbn = ?1", String.class).getSingleResult();
632+
String title = session.createNativeQuery("select title from Books where isbn = ?1", String.class).getSingleResult();
633633
----
634634

635635
However, in general, there isn't enough information in the JDBC `ResultSetMetaData` to infer the mapping of columns to entity objects.
@@ -643,8 +643,8 @@ So if there are any unflushed changes to ``Book``s, this query might return stal
643643
[source,java]
644644
----
645645
List<Book> books =
646-
s.createNativeQuery("select * from Books")
647-
.getResultList()
646+
session.createNativeQuery("select * from Books")
647+
.getResultList()
648648
----
649649

650650
There's two ways to ensure the persistence context is flushed before this query is executed.
@@ -654,19 +654,19 @@ Either, we could simply force a flush by set the flush mode to `ALWAYS`:
654654
[source,java]
655655
----
656656
List<Book> books =
657-
s.createNativeQuery("select * from Books")
658-
.setHibernateFlushMode(ALWAYS)
659-
.getResultList()
657+
session.createNativeQuery("select * from Books")
658+
.setHibernateFlushMode(ALWAYS)
659+
.getResultList()
660660
----
661661

662662
Or, alternative, we could tell Hibernate which modified state affects the results of the query:
663663

664664
[source,java]
665665
----
666666
List<Book> books =
667-
s.createNativeQuery("select * from Books")
668-
.addSynchronizedEntityClass(Book.class)
669-
.getResultList()
667+
session.createNativeQuery("select * from Books")
668+
.addSynchronizedEntityClass(Book.class)
669+
.getResultList()
670670
----
671671

672672

@@ -694,21 +694,21 @@ For example, this:
694694
[source,java]
695695
----
696696
List<Book> books =
697-
s.createSelectionQuery("from Book where title like ?1")
698-
.setParameter(1, titlePatterm)
699-
.setMaxResults(10)
700-
.getResultList();
697+
session.createSelectionQuery("from Book where title like ?1")
698+
.setParameter(1, titlePatterm)
699+
.setMaxResults(10)
700+
.getResultList();
701701
----
702702

703703
is simpler than:
704704

705705
[source,java]
706706
----
707707
List<Book> books =
708-
s.createSelectionQuery("from Book where title like ?1 fetch first ?2 rows only")
709-
.setParameter(1, titlePatterm)
710-
.setParameter(2, 10)
711-
.getResultList();
708+
session.createSelectionQuery("from Book where title like ?1 fetch first ?2 rows only")
709+
.setParameter(1, titlePatterm)
710+
.setParameter(2, 10)
711+
.getResultList();
712712
----
713713

714714
[[named-queries]]
@@ -744,9 +744,10 @@ We execute our named query as follows:
744744

745745
[source,java]
746746
----
747-
em.createNamedQuery("10BooksByTitle")
748-
.setParameter("titlePattern", titlePattern)
749-
.getResultList()
747+
List<Book> books =
748+
entityManager.createNamedQuery("10BooksByTitle")
749+
.setParameter("titlePattern", titlePattern)
750+
.getResultList()
750751
----
751752

752753
Note that the code which executes the named query is not aware of whether the query was written in HQL or in native SQL, making it slightly easier to change and optimize the query later.

documentation/src/main/asciidoc/introduction/Mapping.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -637,7 +637,7 @@ We can get one from the `Session`:
637637

638638
[source,java]
639639
----
640-
LobHelper helper = s.getLobHelper();
640+
LobHelper helper = session.getLobHelper();
641641
book.text = helper.createClob(text);
642642
book.coverArt = helper.createBlob(image);
643643
----
@@ -646,7 +646,7 @@ In principle, the `Blob` and `Clob` objects provide efficient ways to read or st
646646

647647
[source,java]
648648
----
649-
Book book = s.find(Book.class, bookId);
649+
Book book = session.find(Book.class, bookId);
650650
String text = book.text.getSubString(1, textLength);
651651
InputStream bytes = book.images.getBinaryStream();
652652
----

0 commit comments

Comments
 (0)