HHH-11388 - Fix documentation typos
This commit is contained in:
Fábio Ueno
Vlad Mihalcea
parent
f87f1d5b79
commit
380642bc79
|
|
@ -88,8 +88,8 @@ Internally Hibernate uses a registry of basic types when it needs to resolve a s
|
|||
|
||||
[NOTE]
|
||||
====
|
||||
To use these hibernate-spatial types just must add the `hibernate-spatial` dependency to your classpath _and_ use a the `org.hibernate.spatial.SpatialDialect`.
|
||||
See <<spatial>> for more about spatial types.
|
||||
To use these hibernate-spatial types, you must add the `hibernate-spatial` dependency to your classpath _and_ use a `org.hibernate.spatial.SpatialDialect` implementation.
|
||||
See <<spatial>> for more details about spatial types.
|
||||
====
|
||||
|
||||
These mappings are managed by a service inside Hibernate called the `org.hibernate.type.BasicTypeRegistry`, which essentially maintains a map of `org.hibernate.type.BasicType` (a `org.hibernate.type.Type` specialization) instances keyed by a name.
|
||||
|
|
@ -98,7 +98,7 @@ That is the purpose of the "BasicTypeRegistry key(s)" column in the previous tab
|
|||
[[basic-annotation]]
|
||||
==== The `@Basic` annotation
|
||||
|
||||
Strictly speaking, a basic type is denoted with with the `javax.persistence.Basic` annotation.
|
||||
Strictly speaking, a basic type is denoted by the `javax.persistence.Basic` annotation.
|
||||
Generally speaking, the `@Basic` annotation can be ignored, as it is assumed by default.
|
||||
Both of the following examples are ultimately the same.
|
||||
|
||||
|
|
@ -243,7 +243,7 @@ For example, you might want to persist properties of type `java.util.BigInteger`
|
|||
There are two approaches to developing a custom type:
|
||||
|
||||
- implementing a `BasicType` and registering it
|
||||
- implement a `UserType` which doesn't require type registration
|
||||
- implementing a `UserType` which doesn't require type registration
|
||||
|
||||
As a means of illustrating the different approaches, let's consider a use case where we need to support a `java.util.BitSet` mapping that's stored as a VARCHAR.
|
||||
|
||||
|
|
@ -413,8 +413,10 @@ Hibernate supports the mapping of Java enums as basic value types in a number of
|
|||
|
||||
The original JPA-compliant way to map enums was via the `@Enumerated` and `@MapKeyEnumerated` for map keys annotations which works on the principle that the enum values are stored according to one of 2 strategies indicated by `javax.persistence.EnumType`:
|
||||
|
||||
`ORDINAL`:: - stored according to the enum value's ordinal position within the enum class, as indicated by java.lang.Enum#ordinal
|
||||
`STRING`:: - stored according to the enum value's name, as indicated by java.lang.Enum#name
|
||||
`ORDINAL`::
|
||||
stored according to the enum value's ordinal position within the enum class, as indicated by `java.lang.Enum#ordinal`
|
||||
`STRING`::
|
||||
stored according to the enum value's name, as indicated by `java.lang.Enum#name`
|
||||
|
||||
Assuming the following enumeration:
|
||||
|
||||
|
|
@ -457,7 +459,7 @@ include::{extrasdir}/basic/basic-enums-Enumerated-ordinal-persistence-example.sq
|
|||
----
|
||||
====
|
||||
|
||||
In the STRING example, the `phone_type` column is defined as an (nullable) VARCHAR type and would hold:
|
||||
In the STRING example, the `phone_type` column is defined as a (nullable) VARCHAR type and would hold:
|
||||
|
||||
`NULL`:: For null values
|
||||
`LAND_LINE`:: For the `LAND_LINE` enum
|
||||
|
|
@ -813,7 +815,7 @@ Hibernate also allows you to map UUID values, again in a number of ways.
|
|||
====
|
||||
The default UUID mapping is as binary because it represents more efficient storage.
|
||||
However many applications prefer the readability of character storage.
|
||||
To switch the default mapping, simply call `MetadataBuilder.applyBasicType( UUIDCharType.INSTANCE, UUID.class.getName() )`
|
||||
To switch the default mapping, simply call `MetadataBuilder.applyBasicType( UUIDCharType.INSTANCE, UUID.class.getName() )`.
|
||||
====
|
||||
|
||||
==== UUID as binary
|
||||
|
|
@ -831,7 +833,7 @@ Maps the UUID to a String using `java.util.UUID#toString` and `java.util.UUID#fr
|
|||
|
||||
[IMPORTANT]
|
||||
====
|
||||
When using one of the PostgreSQL Dialects, this becomes the default UUID mapping
|
||||
When using one of the PostgreSQL Dialects, this becomes the default UUID mapping.
|
||||
====
|
||||
|
||||
Maps the UUID using PostgreSQL's specific UUID data type.
|
||||
|
|
@ -1017,7 +1019,7 @@ https://docs.oracle.com/javase/8/docs/api/java/sql/PreparedStatement.html#setTim
|
|||
==== JPA 2.1 AttributeConverters
|
||||
|
||||
Although Hibernate has long been offering <<basic-custom-type,custom types>>, as a JPA 2.1 provider,
|
||||
it also supports `AttributeConverter`s as well.
|
||||
it also supports `AttributeConverter` as well.
|
||||
|
||||
With a custom `AttributeConverter`, the application developer can map a given JDBC type to an entity basic type.
|
||||
|
||||
|
|
@ -1262,7 +1264,7 @@ include::{extrasdir}/basic/mapping-generated-Generated-update-example.sql[]
|
|||
===== `@GeneratorType` annotation
|
||||
|
||||
The https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/annotations/GeneratorType.html[`@GeneratorType`] annotation is used so that
|
||||
you can provide a custom generator to ste the value of the currently annotated property.
|
||||
you can provide a custom generator to set the value of the currently annotated property.
|
||||
|
||||
For this reason, the `@GeneratorType` annotation accepts a https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/annotations/GenerationTime.html[`GenerationTime`] enum value
|
||||
and a custom https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/annotations/ValueGenerator.html[`ValueGenerator`] class type.
|
||||
|
|
@ -1466,7 +1468,7 @@ include::{extrasdir}/basic/mapping-column-read-and-write-composite-type-persiste
|
|||
====
|
||||
|
||||
[[mapping-column-formula]]
|
||||
==== @Formula
|
||||
==== `@Formula`
|
||||
|
||||
Sometimes, you want the Database to do some computation for you rather than in the JVM, you might also create some kind of virtual column.
|
||||
You can use a SQL fragment (aka formula) instead of mapping a property into a column. This kind of property is read only (its value is calculated by your formula fragment)
|
||||
|
|
@ -1507,7 +1509,7 @@ The SQL fragment can be as complex as you want and even include subselects.
|
|||
====
|
||||
|
||||
[[mapping-column-where]]
|
||||
==== @Where
|
||||
==== `@Where`
|
||||
|
||||
Sometimes, you want to filter out entities or collections using a custom SQL criteria.
|
||||
This can be achieved using the `@Where` annotation, which can be applied to entities and collections.
|
||||
|
|
@ -1570,7 +1572,7 @@ include::{extrasdir}/basic/mapping-where-collection-query-example.sql[]
|
|||
====
|
||||
|
||||
[[mapping-column-filter]]
|
||||
==== @Filter
|
||||
==== `@Filter`
|
||||
|
||||
The `@Filter` annotation is another way to filter out entities or collections using a custom SQL criteria, for both entities and collections.
|
||||
Unlike the `@Where` annotation, `@Filter` allows you to parameterize the filter clause at runtime.
|
||||
|
|
@ -1652,7 +1654,7 @@ For this reason, the second-level collection cache is limited to storing whole c
|
|||
====
|
||||
|
||||
[[mapping-column-filter-join-table]]
|
||||
==== @FilterJoinTable
|
||||
==== `@FilterJoinTable`
|
||||
|
||||
When using the `@Filter` annotation with collections, the filtering is done against the child entries (entities or embeddables).
|
||||
However, if you have a link table between the parent entity and the child table, then you need to use the `@FilterJoinTable` to filter child entries according to some column contained in the join table.
|
||||
|
|
@ -1702,7 +1704,7 @@ include::{extrasdir}/basic/mapping-filter-join-table-collection-query-example.sq
|
|||
====
|
||||
|
||||
[[mapping-column-any]]
|
||||
==== @Any mapping
|
||||
==== `@Any` mapping
|
||||
|
||||
There is one more type of property mapping.
|
||||
The `@Any` mapping defines a polymorphic association to classes from multiple tables.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[entity]]
|
||||
[[entity]]
|
||||
=== Entity types
|
||||
:sourcedir: ../../../../../test/java/org/hibernate/userguide/locking
|
||||
:extrasdir: extras
|
||||
|
|
@ -228,7 +228,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.
|
||||
`Set` says that the equals/hashCode value for an object should not change while the object is part of the Set.
|
||||
`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.
|
||||
|
||||
Note that this is just a concern when using generated identifiers.
|
||||
|
|
@ -325,7 +325,7 @@ There are 4 available OptimisticLockTypes:
|
|||
`ALL`::
|
||||
performs optimistic locking based on _all_ fields as part of an expanded WHERE clause restriction for the UPDATE/DELETE SQL statements
|
||||
`DIRTY`::
|
||||
performs optimistic locking based on _dirty_ fields as part of an expanded WHERE clause restriction for the UPDATE/DELETE SQL statements.
|
||||
performs optimistic locking based on _dirty_ fields as part of an expanded WHERE clause restriction for the UPDATE/DELETE SQL statements
|
||||
|
||||
[[entity-pojo-optlock-versionless-all]]
|
||||
====== Versionless optimistic locking using `OptimisticLockType.ALL`
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ the implementation using the `hibernate.implicit_naming_strategy` configuration
|
|||
`default`:: for `org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl` - an alias for `jpa`
|
||||
`jpa`:: for `org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl` - the JPA 2.0 compliant naming strategy
|
||||
`legacy-hbm`:: for `org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl` - compliant with the original Hibernate NamingStrategy
|
||||
`legacy-jpa`:: for `org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl` - compliant with the legacy NamingStrategy developed for JPA 1.0, which was unfortunately unclear in many respects regarding implicit naming rules.
|
||||
`legacy-jpa`:: for `org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl` - compliant with the legacy NamingStrategy developed for JPA 1.0, which was unfortunately unclear in many respects regarding implicit naming rules
|
||||
`component-path`:: for `org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl` - mostly follows `ImplicitNamingStrategyJpaCompliantImpl` rules, except that it uses the full composite paths, as opposed to just the ending property part
|
||||
+
|
||||
* reference to a Class that implements the `org.hibernate.boot.model.naming.ImplicitNamingStrategy` contract
|
||||
|
|
|
|||
Loading…
Reference in New Issue