HHH-11388 - Fix documentation typos

This commit is contained in:
Fábio Ueno 2017-01-11 17:00:53 -02:00 committed by Vlad Mihalcea
parent f87f1d5b79
commit 380642bc79
3 changed files with 22 additions and 20 deletions

View File

@ -88,8 +88,8 @@ Internally Hibernate uses a registry of basic types when it needs to resolve a s
[NOTE] [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`. 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 about spatial types. 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. 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]] [[basic-annotation]]
==== The `@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. Generally speaking, the `@Basic` annotation can be ignored, as it is assumed by default.
Both of the following examples are ultimately the same. 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: There are two approaches to developing a custom type:
- implementing a `BasicType` and registering it - 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. 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`: 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 `ORDINAL`::
`STRING`:: - stored according to the enum value's name, as indicated by java.lang.Enum#name 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: 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 `NULL`:: For null values
`LAND_LINE`:: For the `LAND_LINE` enum `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. The default UUID mapping is as binary because it represents more efficient storage.
However many applications prefer the readability of character 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 ==== UUID as binary
@ -831,7 +833,7 @@ Maps the UUID to a String using `java.util.UUID#toString` and `java.util.UUID#fr
[IMPORTANT] [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. 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 ==== JPA 2.1 AttributeConverters
Although Hibernate has long been offering <<basic-custom-type,custom types>>, as a JPA 2.1 provider, 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. 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 ===== `@GeneratorType` annotation
The https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/annotations/GeneratorType.html[`@GeneratorType`] annotation is used so that 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 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. 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]] [[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. 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) 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]] [[mapping-column-where]]
==== @Where ==== `@Where`
Sometimes, you want to filter out entities or collections using a custom SQL criteria. 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. 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]] [[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. 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. 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]] [[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). 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. 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]] [[mapping-column-any]]
==== @Any mapping ==== `@Any` mapping
There is one more type of property mapping. There is one more type of property mapping.
The `@Any` mapping defines a polymorphic association to classes from multiple tables. The `@Any` mapping defines a polymorphic association to classes from multiple tables.

View File

@ -1,4 +1,4 @@
[[entity]] [[entity]]
=== Entity types === Entity types
:sourcedir: ../../../../../test/java/org/hibernate/userguide/locking :sourcedir: ../../../../../test/java/org/hibernate/userguide/locking
:extrasdir: extras :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. 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. 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. Note that this is just a concern when using generated identifiers.
@ -325,7 +325,7 @@ There are 4 available OptimisticLockTypes:
`ALL`:: `ALL`::
performs optimistic locking based on _all_ fields as part of an expanded WHERE clause restriction for the UPDATE/DELETE SQL statements performs optimistic locking based on _all_ fields as part of an expanded WHERE clause restriction for the UPDATE/DELETE SQL statements
`DIRTY`:: `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]] [[entity-pojo-optlock-versionless-all]]
====== Versionless optimistic locking using `OptimisticLockType.ALL` ====== Versionless optimistic locking using `OptimisticLockType.ALL`

View File

@ -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` `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 `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-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 `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 * reference to a Class that implements the `org.hibernate.boot.model.naming.ImplicitNamingStrategy` contract