Este conteúdo não está disponível no idioma selecionado.
5.4. Metadata Alternatives
5.4.1. About Metadata Alternatives Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
XML does not suit all users so there are some alternative ways to define O/R mapping metadata in Hibernate.
5.4.2. Using XDoclet Markup Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Many Hibernate users prefer to embed mapping information directly in sourcecode using XDoclet
@hibernate.tags
. We do not cover this approach in this reference guide since it is considered part of XDoclet. However, we include the following example of the Cat
class with XDoclet mappings:
See the Hibernate website for more examples of XDoclet and Hibernate.
5.4.3. Using JDK 5.0 Annotations Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
JDK 5.0 introduced XDoclet-style annotations at the language level that are type-safe and checked at compile time. This mechanism is more powerful than XDoclet annotations and better supported by tools and IDEs. IntelliJ IDEA, for example, supports auto-completion and syntax highlighting of JDK 5.0 annotations. The new revision of the EJB specification (JSR-220) uses JDK 5.0 annotations as the primary metadata mechanism for entity beans. Hibernate3 implements the
EntityManager
of JSR-220 (the persistence API). Support for mapping metadata is available via the Hibernate Annotations package as a separate download. Both EJB3 (JSR-220) and Hibernate3 metadata is supported.
This is an example of a POJO class annotated as an EJB entity bean:
5.4.4. Generated Properties Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Generated properties are properties that have their values generated by the database. Typically, Hibernate applications needed to
refresh
objects that contain any properties for which the database was generating values. Marking properties as generated, however, lets the application delegate this responsibility to Hibernate. When Hibernate issues an SQL INSERT or UPDATE for an entity that has defined generated properties, it immediately issues a select afterwards to retrieve the generated values.
Properties marked as generated must additionally be non-insertable and non-updateable. Only version, timestamp and property can be marked as generated.
never
(the default): the given property value is not generated within the database.
insert
: the given property value is generated on insert, but is not regenerated on subsequent updates. Properties like created-date fall into this category. Even though the version and timestamp properties can be marked as generated, this option is not available.
always
: the property value is generated both on insert and on update.
5.4.5. Auxiliary Database Objects Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Auxiliary database objects allow for the CREATE and DROP of arbitrary database objects. In conjunction with Hibernate's schema evolution tools, they have the ability to fully define a user schema within the Hibernate mapping files. Although designed specifically for creating and dropping things like triggers or stored procedures, any SQL command that can be run via a
java.sql.Statement.execute()
method is valid (for example, ALTERs, INSERTS, etc.). There are essentially two modes for defining auxiliary database objects:
The first mode is to explicitly list the CREATE and DROP commands in the mapping file:
The second mode is to supply a custom class that constructs the CREATE and DROP commands. This custom class must implement the
org.hibernate.mapping.AuxiliaryDatabaseObject
interface.
Additionally, these database objects can be optionally scoped so that they only apply when certain dialects are used.