You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -228,7 +228,6 @@ Of course, we're not going to cover every useful configuration setting in this c
228
228
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.
229
229
230
230
[TIP]
231
-
// .Ya ain't gunna need 'em
232
231
====
233
232
Hibernate has many—too many—switches and toggles.
234
233
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.
@@ -176,14 +176,14 @@ Using Hibernate's native APIs we might write something really similar,
176
176
// throw e;
177
177
// }
178
178
// finally {
179
-
// s.close();
179
+
// session.close();
180
180
// }
181
181
// ----
182
182
but since this sort of code is extremely tedious, we have a much nicer option:
183
183
184
184
[source,java]
185
185
----
186
-
sf.inTransaction(s -> {
186
+
sessionFactory.inTransaction(session -> {
187
187
//do the work
188
188
...
189
189
});
@@ -347,14 +347,14 @@ For example, to disable flushes that occur before query execution, call:
347
347
348
348
[source,java]
349
349
----
350
-
em.setFlushMode(FlushModeType.COMMIT);
350
+
entityManager.setFlushMode(FlushModeType.COMMIT);
351
351
----
352
352
353
353
Hibernate allows greater control over the flush mode than JPA:
354
354
355
355
[source,java]
356
356
----
357
-
s.setHibernateFlushMode(FlushMode.MANUAL);
357
+
session.setHibernateFlushMode(FlushMode.MANUAL);
358
358
----
359
359
360
360
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:
420
420
[source,java]
421
421
----
422
422
List<Book> matchingBooks =
423
-
s.createSelectionQuery("from Book where title like :titleSearchPattern", Book.class)
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_.
444
444
[source,java]
445
445
----
446
446
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();
450
450
----
451
451
452
452
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
463
463
[source,java]
464
464
----
465
465
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();
469
469
----
470
470
471
471
Or, if we're expecting it to return at most one result, we can use `getSingleResultOrNull()`.
472
472
473
473
[source,java]
474
474
----
475
475
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();
479
479
----
480
480
481
481
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`:
488
488
[source,java]
489
489
----
490
490
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();
495
495
----
496
496
497
497
[CAUTION]
@@ -520,14 +520,14 @@ Using the JPA-standard APIs, this would be a `CriteriaBuilder`, and we get it fr
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:
627
627
628
628
[source, java]
629
629
----
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();
631
631
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();
633
633
----
634
634
635
635
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
643
643
[source,java]
644
644
----
645
645
List<Book> books =
646
-
s.createNativeQuery("select * from Books")
647
-
.getResultList()
646
+
session.createNativeQuery("select * from Books")
647
+
.getResultList()
648
648
----
649
649
650
650
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`:
654
654
[source,java]
655
655
----
656
656
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()
660
660
----
661
661
662
662
Or, alternative, we could tell Hibernate which modified state affects the results of the query:
663
663
664
664
[source,java]
665
665
----
666
666
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()
670
670
----
671
671
672
672
@@ -694,21 +694,21 @@ For example, this:
694
694
[source,java]
695
695
----
696
696
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();
701
701
----
702
702
703
703
is simpler than:
704
704
705
705
[source,java]
706
706
----
707
707
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();
712
712
----
713
713
714
714
[[named-queries]]
@@ -744,9 +744,10 @@ We execute our named query as follows:
744
744
745
745
[source,java]
746
746
----
747
-
em.createNamedQuery("10BooksByTitle")
748
-
.setParameter("titlePattern", titlePattern)
749
-
.getResultList()
747
+
List<Book> books =
748
+
entityManager.createNamedQuery("10BooksByTitle")
749
+
.setParameter("titlePattern", titlePattern)
750
+
.getResultList()
750
751
----
751
752
752
753
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.
0 commit comments