HHH-11317 - Several typos and style fixes in documentation
This commit is contained in:
parent
fc7f0fca73
commit
d5538fc63b
|
@ -43,7 +43,7 @@ Internally Hibernate uses a registry of basic types when it needs to resolve a s
|
|||
|TimeZoneType |VARCHAR, using the TimeZone ID |java.util.TimeZone |timezone, java.util.TimeZone
|
||||
|UrlType |VARCHAR |java.net.URL |url, java.net.URL
|
||||
|ClassType |VARCHAR (class FQN) |java.lang.Class |class, java.lang.Class
|
||||
|BlobType |BLOB |java.sql.Blob |blog, java.sql.Blob
|
||||
|BlobType |BLOB |java.sql.Blob |blob, java.sql.Blob
|
||||
|ClobType |CLOB |java.sql.Clob |clob, java.sql.Clob
|
||||
|BinaryType |VARBINARY |byte[] |binary, byte[]
|
||||
|MaterializedBlobType |BLOB |byte[] |materized_blob
|
||||
|
@ -860,7 +860,7 @@ To avoid dependencies on the `java.sql` package, it's common to use the `java.ut
|
|||
|
||||
While the `java.sql` classes define a direct association to the SQL Date/Time data types,
|
||||
the `java.util` or `java.time` properties need to explicitly mark the SQL type correlation with the `@Temporal` annotation.
|
||||
This way, a `java.util.Date` or a `java.util.Calendar` cn be mapped to either an SQL `DATE`, `TIME` or `TIMESTAMP` type.
|
||||
This way, a `java.util.Date` or a `java.util.Calendar` can be mapped to either an SQL `DATE`, `TIME` or `TIMESTAMP` type.
|
||||
|
||||
Considering the following entity:
|
||||
|
||||
|
@ -1930,4 +1930,4 @@ include::{extrasdir}/basic/mapping-JoinColumnOrFormula-fetching-example.sql[]
|
|||
----
|
||||
====
|
||||
|
||||
Therefore, the `@JoinColumnOrFormula` annotation is used to define a custom join association between the parent-child association.
|
||||
Therefore, the `@JoinColumnOrFormula` annotation is used to define a custom join association between the parent-child association.
|
||||
|
|
|
@ -227,7 +227,7 @@ include::{extrasdir}/entity/listing7.java[]
|
|||
----
|
||||
====
|
||||
|
||||
The issue here is a conflict between _the use of generated identifier_, _the contract of `Set`_ and _the equals/hashCode implementations_.
|
||||
The issue here is a conflict between the use of generated identifier, the contract of `Set` and the equals/hashCode implementations.
|
||||
`Set` says that the equals/hashCode value for an object should not change while the object is part of the Set.
|
||||
But that is exactly what happened here because the equals/hasCode are based on the (generated) id, which was not set until the `session.getTransaction().commit()` call.
|
||||
|
||||
|
|
Loading…
Reference in New Issue