HHH-11317 - Several typos and style fixes in documentation

This commit is contained in:
opporancisis 2016-12-03 19:22:29 +03:00 committed by Vlad Mihalcea
parent fc7f0fca73
commit d5538fc63b
2 changed files with 4 additions and 4 deletions

View File

@ -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.

View File

@ -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.