HHH-18605 fix some minor defects in Hibernate Query Language doc (#8941)
* HHH-18605 fix some minor defects in Hibernate Query Language doc Co-authored-by: nathan.xu <nathan.xu@procor.com>
This commit is contained in:
parent
75ac785517
commit
cef19d79d5
|
@ -334,7 +334,7 @@ For example:
|
|||
|
||||
[source,hql]
|
||||
----
|
||||
delete Author author where is empty author.books
|
||||
delete Author author where author.books is empty
|
||||
----
|
||||
|
||||
As in SQL, the presence or absence of the `from` keyword has absolutely no effect on the semantics of the `delete` statement.
|
||||
|
@ -419,7 +419,7 @@ The `queryExpression` in an `insert ... select` statement may be any valid `sele
|
|||
====
|
||||
This is checked during query compilation rather than allowing the type check to delegate to the database.
|
||||
This may cause problems when two Java types map to the same database type.
|
||||
For example, an attribute of type `LocalDateTime` and an attribute or type `Timestamp` both map to the SQL type `timestamp`, but are not considered assignable by the query compiler.
|
||||
For example, an attribute of type `LocalDateTime` and an attribute of type `Timestamp` both map to the SQL type `timestamp`, but are not considered assignable by the query compiler.
|
||||
====
|
||||
|
||||
There are two ways to assign a value to the `@Id` attribute:
|
||||
|
@ -577,7 +577,7 @@ Indeed, a fairly innocent-looking HQL query can easily translate to a SQL statem
|
|||
====
|
||||
We need to be a _bit_ careful about that, but actually it's usually a good thing.
|
||||
HQL makes it very easy to fetch all the data we need in a single trip to the database, and that's absolutely key to achieving high performance in data access code.
|
||||
Typically, it's much worse to fetch exactly the data we need, but in many round trips to the database server, than it is to fetch just a bit more data than what we're going to need, all a single SQL query.
|
||||
Typically, it's much worse to fetch exactly the data we need, but in many round trips to the database server, than it is to fetch just a bit more data than what we're going to need, all in a single SQL query.
|
||||
====
|
||||
|
||||
When there's no explicit `select` clause, a further abbreviation is sometimes possible.
|
||||
|
@ -609,7 +609,7 @@ The fundamental problem for Java is that it doesn't have tuple types.
|
|||
Queries in Hibernate return tables.
|
||||
Sure, often a column holds whole entity objects, but we're not restricted to returning a single entity, and we often write queries that return multiple entities in each result, or which return things which aren't entities.
|
||||
|
||||
So we're faced with the problem if representing such result sets, and, we're sad to say, there's no fully general and completely satisfying solution.
|
||||
So we're faced with the problem of representing such result sets, and, we're sad to say, there's no fully general and completely satisfying solution.
|
||||
|
||||
Let's begin with the easy case.
|
||||
|
||||
|
@ -641,7 +641,7 @@ When there are multiple expressions in the select list then, by default, and in
|
|||
[%unbreakable]
|
||||
----
|
||||
List<Object[]> results =
|
||||
entityManager.createQuery("select title, left(book.text, 200) from Book",
|
||||
entityManager.createQuery("select title, left(text, 200) from Book",
|
||||
Object[].class)
|
||||
.getResultList();
|
||||
for (var result : results) {
|
||||
|
@ -659,7 +659,7 @@ All we have to do is pass the class `Tuple` to `createQuery()`.
|
|||
[%unbreakable]
|
||||
----
|
||||
List<Tuple> tuples =
|
||||
entityManager.createQuery("select title as title, left(book.text, 200) as preamble from Book",
|
||||
entityManager.createQuery("select title as title, left(text, 200) as preamble from Book",
|
||||
Tuple.class)
|
||||
.getResultList();
|
||||
for (Tuple tuple : tuples) {
|
||||
|
@ -677,7 +677,7 @@ As an extension to JPA, and in a similar vein, Hibernate lets us pass `Map` or `
|
|||
[%unbreakable]
|
||||
----
|
||||
var results =
|
||||
entityManager.createQuery("select title as title, left(book.text, 200) as preamble from Book",
|
||||
entityManager.createQuery("select title as title, left(text, 200) as preamble from Book",
|
||||
Map.class)
|
||||
.getResultList();
|
||||
for (var map : results) {
|
||||
|
@ -689,7 +689,7 @@ for (var map : results) {
|
|||
[%unbreakable]
|
||||
----
|
||||
var results =
|
||||
entityManager.createQuery("select title, left(book.text, 200) from Book",
|
||||
entityManager.createQuery("select title, left(text, 200) from Book",
|
||||
List.class)
|
||||
.getResultList();
|
||||
for (var list : results) {
|
||||
|
@ -699,7 +699,7 @@ for (var list : results) {
|
|||
----
|
||||
|
||||
Unfortunately, not one of the types `Object[]`, `List`, `Map`, nor `Tuple` lets us access an individual item in a result tuple without a type cast.
|
||||
Sure `Tuple` does the type cast for us when we pass a class object to `get()`, but it's logically identical.
|
||||
Sure, `Tuple` does the type cast for us when we pass a class object to `get()`, but it's logically identical.
|
||||
Fortunately there's one more option, as we're about to see.
|
||||
|
||||
[NOTE]
|
||||
|
@ -717,7 +717,7 @@ This works extremely nicely with `record` types.
|
|||
record BookSummary(String title, String summary) {}
|
||||
|
||||
List<BookSummary> results =
|
||||
entityManager.createQuery("select title, left(book.text, 200) from Book",
|
||||
entityManager.createQuery("select title, left(text, 200) from Book",
|
||||
BookSummary.class)
|
||||
.getResultList();
|
||||
for (var result : results) {
|
||||
|
@ -762,7 +762,7 @@ For example, the JPA-standard `select new` construct packages the query results
|
|||
record BookSummary(String title, String summary) {}
|
||||
|
||||
List<BookSummary> results =
|
||||
entityManager.createQuery("select new BookSummary(title, left(book.text, 200)) from Book",
|
||||
entityManager.createQuery("select new BookSummary(title, left(text, 200)) from Book",
|
||||
BookSummary.class)
|
||||
.getResultList();
|
||||
for (var result : results) {
|
||||
|
|
|
@ -259,7 +259,7 @@ An element of a compound path referring to a many-to-one or on-to-one associatio
|
|||
|
||||
[source,hql]
|
||||
----
|
||||
select treat(order.payment as CreditCardPayment).creditCardNumber from Order order
|
||||
select treat(order.payment as CreditCardPayment).cardNumber from Order order
|
||||
----
|
||||
|
||||
If an element of a compound path refers to a collection or many-valued association, it must have one of <<collection-functions,these special functions>> applied to it.
|
||||
|
@ -363,7 +363,7 @@ This default behavior may be changed using configuration property `hibernate.que
|
|||
Setting this property to `true` instructs Hibernate to produce SQL that emulates Java-style integer division (that is, `3/2 = 1`) on platforms where that is not the native semantics.
|
||||
====
|
||||
|
||||
When the operands are of different type, one of the operands is implicitly converted to _wider_ type, with wideness given, in decreasing order, by the list below:
|
||||
When the operands are of different types, one of the operands is implicitly converted to _wider_ type, with wideness given, in decreasing order, by the list below:
|
||||
|
||||
- `Double` (widest)
|
||||
- `Float`
|
||||
|
@ -382,7 +382,7 @@ Many more numeric operations are defined below, in <<exp-functions>>.
|
|||
Arithmetic involving dates, datetimes, and durations is quite subtle.
|
||||
Among the issues to consider are:
|
||||
|
||||
- There's two kinds of duration: year-day, and week-nanosecond durations.
|
||||
- There are two kinds of duration: year-day, and week-nanosecond durations.
|
||||
The first is a difference between dates; the second is a difference between datetimes.
|
||||
- We can subtract dates and datetimes, but we can't add them.
|
||||
- A Java-style duration has much too much precision, and so in order to use it for anything useful, we must somehow truncate it to something coarser-grained.
|
||||
|
@ -787,7 +787,7 @@ select trunc(local datetime, hour)
|
|||
----
|
||||
|
||||
Truncating a date, time or datetime value means obtaining a value of the same type in which all temporal units smaller than `field` have been pruned.
|
||||
For hours, minutes and second this means setting them to `00`. For months and days, this means setting them to `01`.
|
||||
For hours, minutes, and seconds this means setting them to `00`. For months and days, this means setting them to `01`.
|
||||
|
||||
[[string-functions]]
|
||||
==== Functions for working with strings
|
||||
|
@ -1019,7 +1019,7 @@ They're interpreted as referring to the collection as a whole.
|
|||
| `keys()` | Maps | The keys of a map, collectively | ✖
|
||||
| `values()` | Maps | The values of a map, collectively | ✖
|
||||
|===
|
||||
Application of one of these function produces an implicit subquery or implicit join.
|
||||
Application of one of these functions produces an implicit subquery or implicit join.
|
||||
|
||||
This query has an implicit join:
|
||||
|
||||
|
|
|
@ -131,7 +131,7 @@ select id, total
|
|||
from (
|
||||
select ord.id as id, sum(item.book.price * item.quantity) as total
|
||||
from Order as ord
|
||||
join Item as item
|
||||
join ord.items as item
|
||||
group by ord
|
||||
)
|
||||
where total > 100.0
|
||||
|
@ -145,7 +145,7 @@ select stuff.id, stuff.total
|
|||
from (
|
||||
select ord.id as id, sum(item.book.price * item.quantity) as total
|
||||
from Order as ord
|
||||
join Item as item
|
||||
join ord.items as item
|
||||
group by ord
|
||||
) as stuff
|
||||
where total > 100.0
|
||||
|
@ -347,9 +347,9 @@ An explicit join may narrow the type of the joined entity using `treat()`.
|
|||
[source, hql]
|
||||
----
|
||||
from Order as ord
|
||||
join treat(ord.payments as CreditCardPayment) as creditCardPayment
|
||||
where length(creditCardPayment.cardNumber) between 16 and 20
|
||||
select ord.id, creditCardPayment.cardNumber, creditCardPayment.amount
|
||||
join treat(ord.payments as CreditCardPayment) as ccp
|
||||
where length(ccp.cardNumber) between 16 and 20
|
||||
select ord.id, ccp.cardNumber, ccp.amount
|
||||
----
|
||||
|
||||
Here, the identification variable `ccp` declared to the right of `treat()` has the narrowed type `CreditCardPayment`, instead of the declared type `Payment`.
|
||||
|
@ -500,7 +500,7 @@ When a join involves a collection or many-valued association, the declared ident
|
|||
select publisher.name, author.name
|
||||
from Publisher as publisher
|
||||
join publisher.books as book
|
||||
join book.authors author
|
||||
join book.authors as author
|
||||
where author.name like :namePattern
|
||||
----
|
||||
|
||||
|
@ -518,7 +518,7 @@ These functions may be applied to the identification variable declared in a coll
|
|||
| Often optional.
|
||||
| `index()` | Any `List` with an index column | The index of the element in the list
|
||||
| For backward compatibility, it's also an alternative to ``key()``, when applied to a map.
|
||||
| `key()` | Any `Map` | The key of the entry in the list | If the key is of entity type, it may be further navigated.
|
||||
| `key()` | Any `Map` | The key of the entry in the map | If the key is of entity type, it may be further navigated.
|
||||
| `entry()` | Any `Map` | The map entry, that is, the `Map.Entry` of key and value.
|
||||
| Only legal as a terminal path, and only allowed in the `select` clause.
|
||||
|===
|
||||
|
@ -539,7 +539,7 @@ from Book as book
|
|||
select publisher.name, leadAuthor.name
|
||||
from Publisher as publisher
|
||||
join publisher.books as book
|
||||
join book.authors leadAuthor
|
||||
join book.authors as leadAuthor
|
||||
where leadAuthor.name like :namePattern
|
||||
and index(leadAuthor) == 0
|
||||
----
|
||||
|
|
|
@ -141,7 +141,7 @@ But it's better to specify the projection explicitly, except in the simplest cas
|
|||
==== Duplicate removal
|
||||
|
||||
The `distinct` keyword helps remove duplicate results from the query result list.
|
||||
It's only effect is to add `distinct` to the generated SQL.
|
||||
Its only effect is to add `distinct` to the generated SQL.
|
||||
|
||||
[[distinct-projection-query-example]]
|
||||
[source, hql]
|
||||
|
|
Loading…
Reference in New Issue