Hibernate.orgCommunity Documentation

Capítulo 5. Mapeo O/R Básico

5.1. Declaración de mapeo
5.1.1. Doctype
5.1.2. Mapeo de Hibernate
5.1.3. Clase
5.1.4. id
5.1.5. Generadores mejorados del identificador
5.1.6. Optimización del generador del identificador
5.1.7. composite-id
5.1.8. Discriminador
5.1.9. Versión (opcional)
5.1.10. Timestamp (opcional)
5.1.11. Propiedad
5.1.12. Many-to-one
5.1.13. One-to-one
5.1.14. Natural-id
5.1.15. Componente y componente dinámico
5.1.16. Propiedades
5.1.17. Subclase
5.1.18. joined-subclass
5.1.19. Union-subclass
5.1.20. Join
5.1.21. Key
5.1.22. Los elementos columna y fórmula
5.1.23. Import
5.1.24. Any
5.2. Tipos de Hibernate
5.2.1. Entidades y Valores
5.2.2. Tipos de valores básicos
5.2.3. Tipos de valor personalizados
5.3. Mapeo de una clase más de una vez
5.4. Identificadores SQL en comillas
5.5. Alternativas de metadatos
5.5.1. Utilización de marcado de XDoclet
5.5.2. Utlización de Anotaciones JDK 5.0
5.6. Propiedades generadas
5.7. Expresiones de lectura y escritura de columnas
5.8. Objetos de bases de datos auxiliares

Los mapeos objeto/relacional usualmente se definen en un documento XML. El documento de mapeo está diseñado para que se pueda leer y editar a mano. El lenguaje de mapeo está centrado en Java, lo que significa que los mapeos se construyen alrededor de declaraciones de clases persistentes y no alrededor de declaraciones de tablas.

Observe que, incluso aunque muchos de los usuarios de Hibernate eligen escribir el XML a mano, existe un número de herramientas para generar el documento de mapeo, incluyendo XDoclet, Middlegen y AndroMDA.

Este es un ejemplo de mapeo:


<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
      "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
          "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="eg">

        <class name="Cat"
            table="cats"
            discriminator-value="C">

                <id name="id">
                        <generator class="native"/>
                </id>

                <discriminator column="subclass"
                     type="character"/>

                <property name="weight"/>

                <property name="birthdate"
                    type="date"
                    not-null="true"
                    update="false"/>

                <property name="color"
                    type="eg.types.ColorUserType"
                    not-null="true"
                    update="false"/>

                <property name="sex"
                    not-null="true"
                    update="false"/>

                <property name="litterId"
                    column="litterId"
                    update="false"/>

                <many-to-one name="mother"
                    column="mother_id"
                    update="false"/>

                <set name="kittens"
                    inverse="true"
                    order-by="litter_id">
                        <key column="mother_id"/>
                        <one-to-many class="Cat"/>
                </set>

                <subclass name="DomesticCat"
                    discriminator-value="D">

                        <property name="name"
                            type="string"/>

                </subclass>

        </class>

        <class name="Dog">
                <!-- mapping for Dog could go here -->
        </class>

</hibernate-mapping
>

Ahora vamos a discutir el contenido del documento de mapeo. Sólamente describiremos los elementos y atributos del documento que Hibernate utiliza en tiempo de ejecución. El documento de mapeo también comprende algunos atributos y elementos extra opcionales que afectan los esquemas de la base de datos exportados por la herramienta de exportación de esquemas (por ejemplo, el atributo not-null).

Todos los mapeos XML deben declarar el tipo de documento que se muestra. El DTD en sí se puede encontrar en la URL mencionada anteriormente, en el directorio hibernate-x.x.x/src/org/hibernate , o en hibernate3.jar. Hibernate siempre buscará el DTD primero en la ruta de clase. Si el DTD realiza búsquedas utilizando una conexión de Internet, verifique que su declaración DTD frente al contenido de su ruta de clase.

Hibernate tratará primero de resolver los DTDs en su ruta de clase. La manera en que lo hace es registrando una implementación org.xml.sax.EntityResolver personalizada con el SAXReader que utiliza para leer los archivos xml. Este EntityResolver personalizado reconoce dos diferentes espacios de nombre del identificador del sistema.

Este es un ejemplo de la utilización de los espacios de nombre del usuario:


<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC '-//Hibernate/Hibernate Mapping DTD 3.0//EN' 'http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd' [
<!ENTITY version "3.5.6-Final">
<!ENTITY today "September 15, 2010">

    <!ENTITY types SYSTEM "classpath://your/domain/types.xml">


]>


<hibernate-mapping package="your.domain">
    <class name="MyEntity">
        <id name="id" type="my-custom-id-type">
            ...
        </id>
    <class>
    &types;
</hibernate-mapping>

En donde types.xml es un recurso en el paquete your.domain y comprende un typedef personalizado.

Este elemento tiene varios atributos opcionales. Los atributos schema y catalog especifican que las tablas a las que se refiere en este mapeo pertenecen al esquema y/o catálogo mencionado(s). De especificarse, los nombres de tablas serán calificados por el nombre del esquema y del catálogo dados. De omitirse, los nombres de las tablas no serán calificados. El atributo default-cascade especifica qué estilo de cascada se debe asumir para las propiedades y colecciones que no especifican un atributo cascade. Por defecto, el atributo auto-import nos permite utilizar nombres de clase sin calificar en el lenguaje de consulta.

<hibernate-mapping
         schem(1)a="schemaName"
         catal(2)og="catalogName"
         defau(3)lt-cascade="cascade_style"
         defau(4)lt-access="field|property|ClassName"
         defau(5)lt-lazy="true|false"
         auto-(6)import="true|false"
         packa(7)ge="package.name"
 />

1

schema (opcional): El nombre de un esquema de la base de datos.

2

catalog (opcional): El nombre de un catálogo de la base de datos.

3

default-cascade (opcional - por defecto es none): Un estilo de cascada por defecto.

4

default-access (opcional - por defecto es property): La estrategia que Hibernate debe utilizar para acceder a todas las propiedades. Puede ser una implementación personalizada de PropertyAccessor.

5

default-lazy (opcional - por defecto es true): El valor por defecto para los atributos lazy no especificados de mapeos de clase y de colección.

6

auto-import (opcional - por defecto es true): Especifica si podemos utilizar nombres de clases no calificados de clases en este mapeo en el lenguaje de consulta.

7

package (opcional): Especifica un prefijo de paquete que se debe utilizar para los nombres de clase no calificados en el documento de mapeo.

Si tiene dos clases persistentes con el mismo nombre (sin calificar), debe establecer auto-import="false". Se presentará una excepción si usted intenta asignar dos clases al mismo nombre "importado".

El elemento hibernate-mapping le permite anidar varios mapeos <class> persistentes, como se mostró anteriormente. Sin embargo, es una buena práctica (y algunas herramientas esperan) que mapee sólamente una clase persistente, o a una sóla jerarquía de clases, en un archivo de mapeo y nombrarlo como la superclase persistente. Por ejemplo, Cat.hbm.xml, Dog.hbm.xml, o si utiliza herencia, Animal.hbm.xml.

Puede declarar una clase persistente utilizando el elemento class. Por ejemplo:

<class
        name="(1)ClassName"
        table=(2)"tableName"
        discri(3)minator-value="discriminator_value"
        mutabl(4)e="true|false"
        schema(5)="owner"
        catalo(6)g="catalog"
        proxy=(7)"ProxyInterface"
        dynami(8)c-update="true|false"
        dynami(9)c-insert="true|false"
        select(10)-before-update="true|false"
        polymo(11)rphism="implicit|explicit"
        where=(12)"arbitrary sql where condition"
        persis(13)ter="PersisterClass"
        batch-(14)size="N"
        optimi(15)stic-lock="none|version|dirty|all"
        lazy="(16)true|false"
        entity(17)-name="EntityName"
        check=(18)"arbitrary sql check condition"
        rowid=(19)"rowid"
        subsel(20)ect="SQL expression"
        abstra(21)ct="true|false"
        node="element-name"
/>

1

name (opcional): El nombre completamente calificado de la clase Java persistente (o interfaz). Si se omite este atributo, se asume que el mapeo es para una entidad que no es POJO.

2

table (opcional - por defecto es el nombre de la clase no calificado): El nombre de su tabla en la base de datos.

3

discriminator-value (opcional - predeterminado al nombre de la clase): Un valor que distingue subclases individuales, usado para el comportamiento polimórfico. Los valores aceptables incluyen null y not null.

4

mutable (opcional, por defecto es true): Especifica que las instancias de la clase (no) son mutables.

5

schema (opcional): Sobrescribe el nombre del esquema especificado por el elemento raíz <hibernate-mapping>.

6

catalog (opcional): Sobrescribe el nombre del catálogo especificado por el elemento raíz <hibernate-mapping>.

7

proxy (opcional): Especifica una interfaz a utilizar para los proxies de inicialización perezosa. Puede especificar el nombre mismo de la clase.

8

dynamic-update (opcional, por defecto es false): Especifica que el SQL UPDATE debe ser generado en tiempo de ejecución y puede contener sólamente aquellas columnas cuyos valores hayan cambiado.

9

dynamic-insert (opcional, por defecto es false): Especifica que el SQL INSERT debe ser generado en tiempo de ejecución y debe contener sólamente aquellas columnas cuyos valores no son nulos.

10

select-before-update (opcional, por defecto es false): Especifica que Hibernate nunca debe realizar un UPDATE SQL a menos de que se tenga certeza de que realmente se haya modificado un objeto. Sólo cuando un objeto transitorio ha sido asociado con una sesión nueva utilizando update()), Hibernate realizará una SQL SELECT extra para determinar si realmente se necesita un UPDATE.

11

polymorphism (opcional, por defecto es implicit): Determina si se utiliza polimorfismo de consulta implícito o explícito.

12

where (opcional) especifica una condición SQL WHERE arbitraria para utilizarla en la recuperación de objetos de esta clase.

13

persister (opcional): Especifica un ClassPersister personalizado.

14

batch-size (opcional, por defecto es 1) especifica un "tamaño de lote" para buscar instancias de esta clase por identificador.

15

optimistic-lock (opcional, por defecto es version): Determina la estrategia optimista de bloqueo.

(16)

lazy (opcional): La recuperación perezosa se puede deshabilitar por completo al establecer lazy="false".

(17)

entity-name (optional - defaults to the class name): Hibernate3 allows a class to be mapped multiple times, potentially to different tables. It also allows entity mappings that are represented by Maps or XML at the Java level. In these cases, you should provide an explicit arbitrary name for the entity. See Sección 4.4, “Modelos dinámicos” and Capítulo 19, Mapeo XML for more information.

(18)

check (opcional): Una expresión SQL utilizada para generar una restricción check multi-filas para la generación automática de esquemas.

(19)

rowid (opcional): Hibernate puede utilizar los llamados ROWIDs en las bases de datos. Por ejemplo, en Oracle, Hibernate puede utilizar la columna extra rowid para actualizaciones rápidas si usted establece esta opción como rowid. Un ROWID es un detalle de implementación y representa la posición física de la tupla almacenada.

(20)

subselect (opcional): Mapea una entidad inmutable y de sólo lectura a una subselección de base de datos. Es útil si quiere tener una vista en vez de una tabla base. Vea a continuación para obtener más información.

(21)

abstract (opcional): Utilizado para marcar superclases abstractas en las jerarquías <union-subclass>.

Es perfectamente aceptable que la clase persistente mencionada sea una interfaz. Puede declarar clases que implementan esa interfaz utilizando el elemento <subclass>. Puede persistir cualquier clase interna estática. Debe especificar el nombre de la clase utilizando la forma estándar, por ejemplo, e.g.Foo$Bar.

Las clases inmutables, mutable="false", no pueden ser actualizadas o borradas por la aplicación. Esto le permite a Hibernate realizar ciertas optimizaciones menores de rendimiento.

El atributo opcional proxy activa la inicialización perezosa de instancias persistentes de la clase. Hibernate inicialmente retornará proxies CGLIB que implementan la interfaz mencionada. El objeto persistente real será cargado cuando se invoque un método del proxy. Vea "Inicialización de colecciones y proxies" a continuación.

Por polimorfismo implícito se entiende que las instancias de la clase serán devueltas por una consulta que mencione cualquier superclase, o interfaz implementada, o la clase misma; y que las instancias de cualquier subclase de la clase serán retornadas por una petición que nombra a la clase misma. Por polimorfismo explícito se entiende que las instancias de la clase serán devueltas sólo por consultas que mencionen explícitamente la clase. Las consultas que mencionen la clase retornarán sólo instancias de subclases mapeadas dentro de esta declaración <class> como una <subclass> o <joined-subclass>. Para la mayoría de los propósitos el valor por defecto, polymorphism="implicit", resulta apropiado. El polimorfismo explícito es útil cuando dos clases diferentes se encuentran mapeadas a la misma tabla. Esto permite tener una clase "liviana" que contenga un subconjunto de columnas de la tabla.

El atributo persister le permite personalizar la estrategia de persistencia para la clase. Por ejemplo, puede especificar su propia subclase de org.hibernate.persister.EntityPersister, o incluso puede proporcionar una implementación completamente nueva de la interfaz org.hibernate.persister.ClassPersister que implemente, por ejemplo, la persistencia por medio de llamadas a procedimientos almacenados, serialización a archivos planos o LDAP. Para ver un ejemplo simple (de "persistencia" a una Hashtable) consulte org.hibernate.test.CustomPersister.

Los valores de dynamic-update y dynamic-insert no son heredados por las subclases y por lo tanto deben especificarse en los elementos <subclass> o <joined-subclass>. Aunque en algunos casos, estos ajustes pueden incrementar el rendimiento, de hecho en otros casos, podrían disminuirlo.

El uso de select-before-update disminuirá el rendimiento. Es muy útil prevenir que se llame innecesariamente a un disparador de actualización de la base de datos al volver a unir un gráfico de instancias separadas a una Session.

Si activa dynamic-update, usted tendrá la opción de estrategias de bloqueo optimistas:

Le recomendamos mucho que utilice columnas de versión/sello de fecha para el bloqueo optimista con Hibernate. Esta estrategia optimiza el rendimiento y maneja correctamente las modificaciones realizadas a las instancias separadas, (por ejemplo, cuando se utiliza Session.merge()).

Para un mapeo de Hibernate, no hay diferencia entre una vista y una tabla base. Esto es transparente a nivel de base de datos, aunque algunos DBMS no soportan correctamente las vistas, especialmente con las actualizaciones. A veces usted quiere utilizar una vista, pero no puede crear una en la base de datos (por ejemplo, con un esquema heredado). En este caso, usted puede mapear una entidad inmutable de sólo lectura a una expresión de subconsulta SQL dada.


<class name="Summary">
    <subselect>
        select item.name, max(bid.amount), count(*)
        from item
        join bid on bid.item_id = item.id
        group by item.name
    </subselect>
    <synchronize table="item"/>
    <synchronize table="bid"/>
    <id name="name"/>
    ...
</class
>

Declara las tablas con las cuales se debe sincronizar esta entidad, asegurándose de que el auto-vaciado ocurra correctamente y que las consultas frente a la entidad derivada no devuelvan datos desactualizados. El <subselect> se encuentra disponible tanto como un atributo y como un elemento anidado de mapeo.

Las clases mapeadas tienen que declarar la columna de clave primaria de la tabla de la base de datos. La mayoría de las clases también tendrán una propiedad de estilo Javabeans que tenga el identificador único de una instancia. El elemento <id> define el mapeo de esa propiedad a la columna de clave primaria.

<id
        name="(1)propertyName"
        type="(2)typename"
        column(3)="column_name"
        unsave(4)d-value="null|any|none|undefined|id_value"
        access(5)="field|property|ClassName">
        node="element-name|@attribute-name|element/@attribute|."

        <generator class="generatorClass"/>
</id
>

1

name (opcional): El nombre de la propiedad del identificador. s

2

type (opcional): un nombre que indica el tipo de Hibernate.

3

column (opcional - por defecto es el nombre de la propiedad): El nombre de la columna de la clave principal.

4

unsaved-value (opcional - por defecto es un valor "sensible"): Un valor de la propiedad identificadora que indica que una instancia está recién instanciada (sin guardar), distinguiéndola de las instancias separadas que fueron guardadas o cargadas en una sesión previa.

5

access (opcional - por defecto es property): La estrategia que Hibernate debe utilizar para acceder al valor de la propiedad.

Si se omite el atributo name, se asume que la clase no tiene propiedad identificadora.

El atributo unsaved-value casi nunca se necesita en Hibernate3.

Hay una declaración <composite-id> opcional para permitir acceso a los datos heredados con claves compuestas. Le disuadimos seriamente de su utilización para cualquier otra cosa.

El elemento hijo opcional <generator> nombra una clase Java utilizada para generar identificadores únicos para instancias de la clase persistente. De requerirse algún parámetro para configurar o inicializar la instancia del generador, se pasa utilizando el elemento <param>.


<id name="id" type="long" column="cat_id">
        <generator class="org.hibernate.id.TableHiLoGenerator">
                <param name="table"
>uid_table</param>
                <param name="column"
>next_hi_value_column</param>
        </generator>
</id
>

Todos los generadores implementan la interfaz org.hibernate.id.IdentifierGenerator. Esta es una interfaz muy simple. Algunas aplicaciones pueden decidir brindar sus propias implementaciones especializadas. Sin embargo, Hibernate provee un rango de implementaciones ya incorporadas. Los nombres de atajo para los generadores incorporados son los siguientes:

increment

genera indentificadores de tipo long, short o int que sólamente son únicos cuando ningún otro proceso está insertando datos en la misma tabla. No lo utilice en un clúster.

identity

soporta columnas de identidad en DB2, MySQL, MS SQL Server, Sybase y HypersonicSQL. El identificador devuelto es de tipo long, short o int.

sequence

usa una secuencia en DB2, PostgreSQL, Oracle, SAP DB, McKoi o un generador en Interbase. El identificador devuelto es de tipo long, short o int.

hilo

utiliza un algoritmo alto/bajo para generar eficientemente identificadores de tipo long, short o int, dada una tabla y columna como fuente de valores altos (por defecto hibernate_unique_key y next_hi respectivamente). El algoritmo alto/bajo genera identificadores que son únicos sólamente para una base de datos particular.

seqhilo

utiliza un algoritmo alto/bajo para generar eficientemente identificadores de tipo long, short o int, dada una secuencia de base de datos.

uuid

utiliza un algoritmo UUID de 128 bits para generar identificadores de tipo cadena, únicos dentro de una red (se utiliza la direccón IP). El UUID se codifica como una cadena hexadecimal de 32 dígitos de largo.

guid

utiliza una cadena GUID generada por base de datos en MS SQL Server y MySQL.

native

selecciona identity, sequence o hilo dependiendo de las capacidades de la base de datos subyacente.

assigned

deja a la aplicación asignar un identificador al objeto antes de que se llame a save(). Esta es la estrategia por defecto si no se especifica un elemento <generator>.

select

recupera una clave principal asignada por un disparador de base de datos seleccionando la fila por alguna clave única y recuperando el valor de la clave principal.

foreign

utiliza el identificador de otro objeto asociado. Generalmente se usa en conjunto cón a una asociación de clave principal <one-to-one>.

sequence-identity

una estrategia de generación de secuencias especilizadas que utiliza una secuencia de base de datos para el valor real de la generación, pero combina esto junto con JDBC3 getGeneratedKeys para devolver el valor del identificador generado como parte de la ejecución de la declaración de inserción. Esta estrategia está soportada sólamente en los controladores 10g de Oracle destinados para JDK1.4. Los comentarios en estas declaraciones de inserción están desactivados debido a un error en los controladores de Oracle.

Desde el lanzamiento 3.2.3, hay 2 nuevos generadores, los cuales representan una nueva reflexión sobre dos aspectos diferentes de la generación del identificador. El primer aspecto es qúe tan portátil es la base de datos; el segudno es la optimización. La optimización significa que no tiene que preguntarle a la base de datos por toda petición de un nuevo valor identificador. Estos dos nuevos generadores tienen el propósito de tomar el lugar de algunos de los generadores nombrados que describimos anteriormente, empezando por 3.3.x. Sin embargo, están incluídos en los lanzamientos actuales y puede ser referenciados por FQN.

El primero de estos nuevos generadores es org.hibernate.id.enhanced.SequenceStyleGenerator, el cual tiene el propósito, primero, de ser el reemplazo para el generador sequence y segundo, de ser un generador de portabilidad mejor que native. Esto se debe a que native generalmente escoge entre identity y sequence, los cuales tienen una gran diferencia semántica que puede crear problemas sutiles en las aplicaciones mirando la portabilidad. Sin embargo, org.hibernate.id.enhanced.SequenceStyleGenerator, logra la portabilidad de una manera diferente. Escoge entre una tabla o una secuencia en la base de datos para almacenar sus valores en subida, dependiendo de las capacidades del dialecto que se está utilizando. La diferencia enter esto y native es que el almacenamiento basado en tablas y secuencias tienen la misma semántica. De hecho, las secuencias son exactamente lo que Hibernate trata de emular con sus generadores basados en tablas. Este generador tiene un número de parámetros de configuración:

El segundo de estos nuevos generadores es org.hibernate.id.enhanced.TableGenerator, el cual tiene el propósito, primero, de reemplazar el generador table, auqnue de hecho funciona como org.hibernate.id.MultipleHiLoPerTableGenerator, y segundo, como una re-implementación de org.hibernate.id.MultipleHiLoPerTableGenerator que utiliza la noción de los optimizadores enchufables. Esencialmente, este generador define una tabla capaz de mantener un número de valores de incremento diferentes de manera simultánea usando múltiples filas tecleadas claramente. Este generador tiene un número de parámetros de configuración:

  • table_name (opcional - por defecto es hibernate_sequences): el nombre de la tabla a utilizar.

  • value_column_name (opcional - por defecto es next_val): el nombre de la columna en la tabla que se utiliza para mantener el valor.

  • segment_column_name (opcional - por defecto es sequence_name): el nombre de la columna en la tabla que se utiliza para mantener la "llave segmento". Este es el valor que identifica que valor de incremento utilizar.

  • segment_value (opcional - por defecto es default): El valor "llave segmento" para el segmento desde el cual queremos sacar los valores de incremento para este generador.

  • segment_value_length (opcional - por defecto es 255): Se utiliza para la generación de esquemas; el tamaño de la columna a crear esta columna de llave de segmento.

  • initial_value (opcional - por defecto es 1): El valor inicial a recuperar de la tabla.

  • increment_size (opcional - por defecto es 1): El valor por el cual deben diferir las llamadas subsecuentes a la tabla.

  • optimizer (optional - defaults to ): See Sección 5.1.6, “Optimización del generador del identificador”

For identifier generators that store values in the database, it is inefficient for them to hit the database on each and every call to generate a new identifier value. Instead, you can group a bunch of them in memory and only hit the database when you have exhausted your in-memory value group. This is the role of the pluggable optimizers. Currently only the two enhanced generators (Sección 5.1.5, “Generadores mejorados del identificador” support this operation.

  • none (generalmente este el es valor predeterminado si no se especifica un optimizador): esto no realizará ninguna optimización y accederá a la base de datos para toda petición.

  • hilo: aplica un algoritmo hi/lo a los valores recuperados de la base de datos. Se espera que los valores de la base de datos para este optimizador sean secuenciales. Los valores recuperados de la estructura de la base de datos para este optimizador indican el "número del grupo". El increment_size se multiplica por ese valor en la memoria para definir un grupo "hi value".

  • pooled: como en el caso de hilo, este optimizador trata de minimizar el número de hits a la base de datos. Sin embargo, aquí simplemente almacenamos el valor inicial para el "siguiente grupo" en la estructura de la base de datos en lugar de un valor secuencial en combinación con un algoritmo de agrupamiento en-memoria. Aquí, increment_size ser refiere a los valores que provienen de la base de datos.


<composite-id
        name="propertyName"
        class="ClassName"
        mapped="true|false"
        access="field|property|ClassName">
        node="element-name|."

        <key-property name="propertyName" type="typename" column="column_name"/>
        <key-many-to-one name="propertyName" class="ClassName" column="column_name"/>
        ......
</composite-id
>

Una tabla con clave compuesta se puede mapear con múltiples propiedades de la clase como propiedades identificadoras. El elemento <composite-id> acepta los mapeos de propiedad <key-property> y los mapeos <key-many-to-one> como elementos hijos.


<composite-id>
        <key-property name="medicareNumber"/>
        <key-property name="dependent"/>
</composite-id
>

La clase persistente tiene que sobrescribir equals() y hashCode() para implementar la igualdad del identificador compuesto. También tiene que implementar Serializable.

Desafortunadamente, este enfoque significa que un objeto persistente es su propio identificador. No existe otra "asa" conveniente más que el objeto mismo. Debe instanciar una instancia de la clase persistente y poblar sus propiedades identificadoras antes de que pueda load() el estado persistente asociado a una clave compuesta. Este enfoque lo denominamos un identificador compuesto incluído y no lo recomendamos para aplicaciones serias.

Un segundo enfoque es lo que denominamos un identificador compuesto mapeado, en donde las propiedades del identificador nombradas dentro del elemento <composite-id> son duplicadas tanto en la clase persistente como en la clase identificadora separada.


<composite-id class="MedicareId" mapped="true">
        <key-property name="medicareNumber"/>
        <key-property name="dependent"/>
</composite-id
>

En este ejemplo, tanto la clase identificadora compuesta MedicareId como la clase de entidad misma tienen propiedades denominadas medicareNumber y dependent. La clase identificadora tiene que sobrescribir equals() y hashCode() e implementar Serializable. La desventaja principal de este enfoque es la duplicación de código.

Los siguientes atributos se utilizan para especificar un identificador compuesto mapeado:

We will describe a third, even more convenient approach, where the composite identifier is implemented as a component class in Sección 8.4, “Componentes como identificadores compuestos”. The attributes described below apply only to this alternative approach:

  • name (opcional, se necesita para este enfoque): Una propiedad de tipo componente que tiene el identificador compuesto. Consulte el capítulo 9 para obtener mayor información.

  • access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

  • class (opcional - por defecto es el tipo de propiedad determinado por la reflección): la clase componente utilizada como un identificador compuesto. Vea la siguiente sección para obtener mayor información.

Este tercer enfoque, un componente identificador es el que recomendamos para casi todas las aplicaciones.

Se necesita el elemento <discriminator> para la persistencia polimórfica utilizando la estrategia de mapeo de tabla-por-jerarquía-de-clases. Declara una columna discriminadora de la tabla. La columna discriminidora contiene valores de marca que le dicen a la capa de persistencia qué subclase instanciar para una fila en particular. Se puede utilizar un conjunto restringido de tipos: string, character, integer, byte, short, boolean, yes_no, true_false.

<discriminator
        column(1)="discriminator_column"
        type="(2)discriminator_type"
        force=(3)"true|false"
        insert(4)="true|false"
        formul(5)a="arbitrary sql expression"
/>

1

column (opcional - por defecto es class) el nombre de la columna discriminadora.

2

type (opcional - por defecto es string) un nombre que indica el tipo Hibernate.

3

force (opcional - por defecto es false) "fuerza" a Hibernate para especificar los valores discriminadores permitidos incluso cuando se recuperan todas las instancias de la clase raíz.

4

insert (opcional - por defecto es true): establecido como false si su columna discriminadora también es parte de un identificador mapeado compuesto. Lle dice a Hibernate que no incluya la columna en los SQLs INSERT.

5

formula (opcional): una expresión SQL arbitraria que se ejecuta cuando se tenga que evaluar un tipo. Permite la discriminación con base en el contenido.

Los valores reales de la columna discriminadora están especificados por el atributo discriminator-value de los elementos <class> y <subclass>.

El atributo force es sólamente útil si la tabla contiene filas con valores discriminadores "extra" que no estén mapeados a una clase persistente. Generalmente este no es el caso.

El atributo formula le permite declarar una expresión SQL arbitraria que será utilizada para evaluar el tipo de una fila. Por ejemplo:


<discriminator
    formula="case when CLASS_TYPE in ('a', 'b', 'c') then 0 else 1 end"
    type="integer"/>

El elemento <version> es opcional e indica que la tabla contiene datos versionados. Esto es particularmente útil si planea utilizar transacciones largas. Vea a continuación para obtener mayor información:

<version
        column(1)="version_column"
        name="(2)propertyName"
        type="(3)typename"
        access(4)="field|property|ClassName"
        unsave(5)d-value="null|negative|undefined"
        genera(6)ted="never|always"
        insert(7)="true|false"
        node="element-name|@attribute-name|element/@attribute|."
/>

1

column (opcional - por defecto es el nombre de la propiedad): El nombre de la columna que tiene el número de la versión.

2

name: El nombre de una propiedad de la clase persistente.

3

type (opcional - por defecto es integer): El tipo del número de la versión.

4

access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

5

unsaved-value (opcional - por defecto es undefined): Un valor de la propiedad de versión que indica que una instancia se encuentra recién instanciada (sin guardar), distinguiéndola de las instancias separadas que se guardaron o se cargaron en una sesión previa. undefined especifica que se debe utilizar el valor de la propiedad identificadora.

6

generated (opcional - por defecto es never): Especifica que este valor de la propiedad de la versión es generado por la base de datos. Vea la discusión de las propiedades generadas para obtener mayor información.

7

insert (opcional - por defectos es true): Especifica si la columna de la versión debe incluirse en las declaraciones de inserción SQL. Se puede configurar como false si la columna de la base de datos se define con un valor predeterminado de 0.

Los números de versión pueden ser de tipo Hibernate long, integer, short, timestamp o calendar.

Una propiedad de versión o de sello de fecha nunca debe ser nula para una instancia separada. Hibernate detectará cualquier instancia con una versión o sello de fecha nulo como transitoria, sin importar qué otras estrategias unsaved-value se hayan especificado. El declarar una propiedad de versión o sello de fecha nulable es una forma fácil de evitar cualquier problema con la re-unión transitiva en Hibernate. Es especialmente útil para la gente que utiliza identificadores asignados o claves compuestas.

El elemento opcional <timestamp> indica que la tabla contiene datos con sellos de fecha. Esto brinda una alternativa al versionado. Los sellos de tiempo (timestamps) son por naturaleza una implementación menos segura del bloqueo optimista. Sin embargo, a veces la aplicación puede usar los sellos de fecha de otras maneras.

<timestamp
        column(1)="timestamp_column"
        name="(2)propertyName"
        access(3)="field|property|ClassName"
        unsave(4)d-value="null|undefined"
        source(5)="vm|db"
        genera(6)ted="never|always"
        node="element-name|@attribute-name|element/@attribute|."
/>

1

column (opcional - por defecto es el nombre de la propiedad): El nombre de una columna que tiene el sello de fecha.

2

name: El nombre de una propiedad del estilo JavaBeans de tipo Java Date o Timestamp de la clase persistente.

3

access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

4

unsaved-value (opcional - por defecto es null): Un valor de propiedad de versión que indica que una instancia está recién instanciada (sin guardar), distinguiéndola de instancias separadas que hayan sido guardadas o cargadas en una sesión previa. Undefined especifica que debe utilizarse el valor de la propiedad identificadora.

5

source (opcional - por defecto es vm): ¿Desde dónde debe recuperar Hibernate el valor del sello de fecha? ¿Desde la base de datos o desde la MVJ actual? Los sellos de fecha con base en la base de datos provocan un gasto general debido a que Hibernate tiene que llegar hasta la base de datos para poder determinar el "siguiente valor". Es más seguro utilizarlo en entornos con clústers. No todos los Dialects soportan la recuperación del sello de fecha actual de la base de datos. Los otros pueden ser poco seguros para utilizarlos como bloqueo debido a la falta de precisión (por ejemplo, Oracle 8).

6

generated (opcional - por defecto es never): Especifica que este valor de la propiedad del sello de fecha en realidad es generado por la base de datos. Consulte la discusión de las propiedades generadas para obtener mayor información.

El elemento <property> declara una propiedad persistente estilo JavaBean de la clase.

<property
        name="(1)propertyName"
        column(2)="column_name"
        type="(3)typename"
        update(4)="true|false"
        insert(4)="true|false"
        formul(5)a="arbitrary SQL expression"
        access(6)="field|property|ClassName"
        lazy="(7)true|false"
        unique(8)="true|false"
        not-nu(9)ll="true|false"
        optimi(10)stic-lock="true|false"
        genera(11)ted="never|insert|always"
        node="element-name|@attribute-name|element/@attribute|."
        index="index_name"
        unique_key="unique_key_id"
        length="L"
        precision="P"
        scale="S"
/>

1

name: el nombre de la propiedad, con la letra inicial en minúscula.

2

column (opcional - por defecto es el nombre de la propiedad): El nombre de la columna de la tabla de base de datos mapeada. Esto se puede especificar también con los elemento(s) anidado(s) <column>.

3

type (opcional): un nombre que indica el tipo de Hibernate.

4

update, insert (opcional - por defecto es true): Especifica que las columnas mapeadas deben ser incluídas en las declaraciones SQL UPDATE y/o INSERT . Especificando ambas como false permite una propiedad "derivada", cuyo valor se inicia desde alguna otra propiedad que mapee a la misma columna (o columnas) o por un disparador u otra aplicación.

5

formula (opcional): una expresión SQL que define el valor para una propiedad computada. Las propiedades computadas no tienen una columna mapeada propia.

6

access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

7

lazy (opcional - por defecto es false): Especifica que se debe recuperar perezosamente esta propiedad cuando se acceda por primera vez la variable de instancia. Requiere instrumentación de código byte en tiempo de compilación.

8

unique (opcional): Activa la generación DDL de una restricción de unicidad para las columnas. Además, permite que ésta sea el objetivo de una property-ref.

9

not-null (opcional): Activa la generación DDL de una restricción de nulabilidad para las columnas.

10

optimistic-lock (opcional - por defecto es true): Especifica que las actualizaciones a esta propiedad requieren o no de la obtención de un bloqueo optimista. En otras palabras, determina si debe ocurrir un incremento de versión cuando la propiedad se encuentre desactualizada.

11

generated (opcional - por defecto es never): Especifica que este valor de la propiedad es de hecho generado por la base de datos. Consulte discusión sobre las propiedades generadas para obtener mayor información.

escribanombre puede ser:

Si no especifica un tipo, Hibernate utilizará reflección sobre la propiedad mencionada para deducir el tipo Hibernate correcto. Hibernate intentará interpretar el nombre de la clase de retorno del getter de la propiedad utilizando las reglas 2, 3 y 4 en ese mismo orden. En algunos casos necesitará el atributo type. Por ejemplo, para distinguir entre Hibernate.DATE y Hibernate.TIMESTAMP, o especificar un tipo personalizado.

El atributo access le permite controlar el cómo Hibernate accederá a la propiedad en tiempo de ejecución. Por defecto, Hibernate llamará al par de getter/setter de la propiedad. Si usted especifica access="field", Hibernate se saltará el par get/set y accederá al campo directamente utilizando reflección. Puede especificar su propia estrategia de acceso a la propiedad mencionando una clase que implemente la interfaz org.hibernate.property.PropertyAccessor.

Una funcionalidad especialmente poderosa son las propiedades derivadas. Estas propiedades son, por definición, de sólo lectura. El valor de la propiedad se computa en tiempo de carga. Usted declara la computación como una expresión SQL y ésta se traduce como una cláusula de subconsulta SELECT en la consulta SQL que carga una instancia:



<property name="totalPrice"
    formula="( SELECT SUM (li.quantity*p.price) FROM LineItem li, Product p
                WHERE li.productId = p.productId
                AND li.customerId = customerId
                AND li.orderNumber = orderNumber )"/>

Puede referenciar la tabla de las entidades sin declarar un alias o una columna particular. En el ejemplo dado sería customerId. También puede utilizar el elemento anidado de mapeo <formula> si no quiere utilizar el atributo.

Una asociación ordinaria a otra clase persistente se declara utilizando el elemento many-to-one. El modelo relacional es una asociación muchos-a-uno; una clave foránea en una tabla referencia la columna (o columnas) de la clave principal de la tabla destino.

<many-to-one
        name="(1)propertyName"
        column(2)="column_name"
        class=(3)"ClassName"
        cascad(4)e="cascade_style"
        fetch=(5)"join|select"
        update(6)="true|false"
        insert(6)="true|false"
        proper(7)ty-ref="propertyNameFromAssociatedClass"
        access(8)="field|property|ClassName"
        unique(9)="true|false"
        not-nu(10)ll="true|false"
        optimi(11)stic-lock="true|false"
        lazy="(12)proxy|no-proxy|false"
        not-fo(13)und="ignore|exception"
        entity(14)-name="EntityName"
        formul(15)a="arbitrary SQL expression"
        node="element-name|@attribute-name|element/@attribute|."
        embed-xml="true|false"
        index="index_name"
        unique_key="unique_key_id"
        foreign-key="foreign_key_name"
/>

1

name: El nombre de la propiedad.

2

column (opcional): El nombre de la columna de la clave foránea. Esto también se puede especificar por medio de uno o varios elementos anidados <column>.

3

class (opcional - por defecto es el tipo de la propiedad determinado por reflección): El nombre de la clase asociada.

4

cascade (opcional) especifica qué operaciones deben ir en cascada desde el objeto padre hasta el objeto asociado.

5

fetch (opcional - por defecto es select): Escoge entre la recuperación de unión exterior (outer-join) o la recuperación por selección secuencial.

6

update, insert (opcional - por defecto es true) especifica que las columnas mapeadas deben ser incluídas en las declaraciones SQL UPDATE y/o INSERT. El establecer ambas como false permite una asociación puramente "derivada" cuyo valor es inicializado desde alguna otra propiedad que mapea a la misma columna (o columnas), por un disparador o por otra aplicación.

7

property-ref: (opcional): El nombre de una propiedad de la clase asociada que se encuentra unida a su llave foránea. Si no se especifica, se utiliza la llave principal de la clase asociada.

8

access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

9

unique (opcional): Activa la generación DDL de una restricción de unicidad para la columna de clave foránea. Además, permite que éste sea el objetivo de una property-ref. puede hacer que la asociación sea de multiplicidad uno-a-uno.

10

not-null (opcional): Activa la generación DDL de una restricción de nulabilidad para las columnas de clave foránea.

11

optimistic-lock (opcional - por defecto es true): Especifica que las actualizaciones a esta propiedad requieren o no de la obtención de un bloqueo optimista. En otras palabras, determina si debe ocurrir un incremento de versión cuando la propiedad se encuentre desactualizada.

12

lazy (opcional - por defecto es proxy): Por defecto, las asociaciones de punto único van con proxies. lazy="no-proxy" especifica que esta propiedad debe ser recuperada perezosamente cuando se acceda por primera vez a la variable de instancia. Requiere instrumentación del código byte en tiempo de compilación. lazy="false" especifica que la asociación siempre será recuperada tempranamente.

13

not-found (opcional - por defecto es exception): Especifica cómo se manejarán las claves foráneas que referencian las filas que hacen falta. ignore tratará una fila perdida como una asociación nula.

14

entity-name (opcional): El nombre de entidad de la clase asociada.

15

formula (opcional): una expresión SQL que define el valor para una clave foránea computada.

Setting a value of the cascade attribute to any meaningful value other than none will propagate certain operations to the associated object. The meaningful values are divided into three categories. First, basic operations, which include: persist, merge, delete, save-update, evict, replicate, lock and refresh; second, special values: delete-orphan; and third, all comma-separated combinations of operation names: cascade="persist,merge,evict" or cascade="all,delete-orphan". See Sección 10.11, “Persistencia transitiva” for a full explanation. Note that single valued, many-to-one and one-to-one, associations do not support orphan delete.

Este es un ejemplo de una declaración típica muchos-a-uno:


<many-to-one name="product" class="Product" column="PRODUCT_ID"/>

El atributo property-ref se debe utilizar sólamente para el mapeo de datos heredados donde una clave foránea referencia una clave única de la tabla asociada, distinta de la clave principal. Este es un modelo relacional complicado y confuso. Por ejemplo, si la clase Product tuviera un número único serial que no es la clave principal, el atributo unique controla la generación de DDL de Hibernate con la herramienta SchemaExport.


<property name="serialNumber" unique="true" type="string" column="SERIAL_NUMBER"/>

Entonces el mapeo para OrderItem puede utilizar:


<many-to-one name="product" property-ref="serialNumber" column="PRODUCT_SERIAL_NUMBER"/>

Sin embargo, esto ciertamente no se aconseja.

Si la clave única referenciada abarca múltiples propiedades de la entidad asociada, debe mapear las propiedades dentro de un elemento nombrado <properties>.

Si la clave única referenciada es propiedad de un componente, usted puede especificar una ruta de propiedad:


<many-to-one name="owner" property-ref="identity.ssn" column="OWNER_SSN"/>

Una asociación uno-a-uno (one-to-one) a otra clase persistente se declara utilizando un elemento one-to-one.

<one-to-one
        name="(1)propertyName"
        class=(2)"ClassName"
        cascad(3)e="cascade_style"
        constr(4)ained="true|false"
        fetch=(5)"join|select"
        proper(6)ty-ref="propertyNameFromAssociatedClass"
        access(7)="field|property|ClassName"
        formul(8)a="any SQL expression"
        lazy="(9)proxy|no-proxy|false"
        entity(10)-name="EntityName"
        node="element-name|@attribute-name|element/@attribute|."
        embed-xml="true|false"
        foreign-key="foreign_key_name"
/>

1

name: El nombre de la propiedad.

2

class (opcional - por defecto es el tipo de la propiedad determinado por reflección): El nombre de la clase asociada.

3

cascade (opcional) especifica qué operaciones deben ir en cascada desde el objeto padre hasta el objeto asociado.

4

constrained (opcional): especifica que una restricción de clave foránea en la clave principal de la tabla mapeada referencia la tabla de la clase asociada. Esta opción afecta el orden en que van en la cascada save() y delete() y determina si la asociación puede ser virtualizada por proxies. La herramienta de exportación de esquemas también lo utiliza.

5

fetch (opcional - por defecto es select): Escoge entre la recuperación de unión exterior (outer-join) o la recuperación por selección secuencial.

6

property-ref (opcional): El nombre de una propiedad de la clase asociada que esté unida a la clave principal de esta clase. Si no se especifica, se utiliza la clave principal de la clase asociada.

7

access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

8

formula (opcional): Casi todas las asociaciones uno-a-uno mapean a la clave principal de la entidad propietaria. Si este no es el caso, puede especificar otra columna, o columnas, o una expresión para unir utilizando una fórmula SQL. Para un obtener un ejemplo consulte org.hibernate.test.onetooneformula.

9

lazy (opcional - por defecto es proxy): Por defecto, las asociaciones de punto único van con proxies. lazy="no-proxy" especifica que esta propiedad debe ser traída perezosamente cuando se acceda por primera vez la variable de instancia. Requiere instrumentación del código byte en tiempo de compilación. lazy="false" especifica que la asociación siempre será recuperada tempranamente. Observe que si constrained="false", la aplicación de proxies es imposible e Hibernate recuperará tempranamente la asociación.

10

entity-name (opcional): El nombre de entidad de la clase asociada.

Existen dos variedades de asociaciones uno-a-uno:

Las asociaciones de claves principales no necesitan una columna extra de la tabla. Si dos filas están relacionadas por la asociación entonces las dos filas de tablas comparten el mismo valor de clave principal. Para que dos objetos estén relacionados por una asociación de clave principal, asegúrese de que se les asigne el mismo valor de identificador.

Para una asociación de clave principal, agregue los siguientes mapeos a Employee y Person respectivamente:


<one-to-one name="person" class="Person"/>

<one-to-one name="employee" class="Employee" constrained="true"/>

Asegúrese de que las claves principales de las filas relacionadas en las tablas PERSON y EMPLOYEE sean iguales. Utilizamos una estrategia especial de generación de identificador de Hibernate denominada foreign:


<class name="person" table="PERSON">
    <id name="id" column="PERSON_ID">
        <generator class="foreign">
            <param name="property"
>employee</param>
        </generator>
    </id>
    ...
    <one-to-one name="employee"
        class="Employee"
        constrained="true"/>
</class
>

A una instancia recién guardada de Person se le asigna el mismo valor de clave principal que se le asignó a la instancia Employee referida por la propiedad employee de esa Person.

Opcionalmente, una clave foránea con una restricción de unicidad, desde Employee a Person, se puede expresar como:


<many-to-one name="person" class="Person" column="PERSON_ID" unique="true"/>

Esta asociación puede hacerse bidireccional agregando lo siguiente al mapeo de Person:


<one-to-one name="employee" class="Employee" property-ref="person"/>

El elemento <component> mapea propiedades de un objeto hijo a columnas de la tabla de la clase padre. Los componentes pueden, a su vez, declarar sus propias propiedades, componentes o colecciones. Vea a continuación los "componentes":

<component
        name="(1)propertyName"
        class=(2)"className"
        insert(3)="true|false"
        update(4)="true|false"
        access(5)="field|property|ClassName"
        lazy="(6)true|false"
        optimi(7)stic-lock="true|false"
        unique(8)="true|false"
        node="element-name|."
>

        <property ...../>
        <many-to-one .... />
        ........
</component
>

1

name: El nombre de la propiedad.

2

class (opcional - por defecto es el tipo de la propiedad determinado por reflección): El nombre de la clase del componente (hijo).

3

insert: ¿Las columnas mapeadas aparacen en INSERTs SQL?

4

update: ¿Las columnas mapeadas aparacen en UPDATEs SQL?

5

access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

6

lazy (opcional - por defecto es false): Especifica que este componente debe ser recuperado perezosamente cuando se acceda a la variable de instancia por primera vez. Requiere instrumentación de código byte en tiempo de compilación.

7

optimistic-lock (opcional - por defecto es true): Especifica que las actualizaciones de este componente requieren o no la adquisición de un bloqueo optimista. Determina si debe ocurrir un incremento de versión cuando esta propiedad se encuentra desactualizada.

8

unique (opcional - por defecto es false): Especifica que existe una restricción de unicidad sobre todas las columnas mapeadas del componente.

Las etiquetas hijas <property> mapean propiedades de la clase hija a las columnas de la tabla.

El elemento <component> permite un subelemento <parent> que mapea una propiedad de la clase del componente como una referencia a la entidad contenedora.

The <dynamic-component> element allows a Map to be mapped as a component, where the property names refer to keys of the map. See Sección 8.5, “Componentes dinámicos” for more information.

El elemento <properties> permite la definición de un grupo de propiedades lógico con nombre de una clase. El uso más importante de la contrucción es que permite que una combinación de propiedades sea el objetivo de una property-ref. También es una forma práctica de definir una restricción de unicidad multicolumna. Por ejemplo:

<properties
        name="(1)logicalName"
        insert(2)="true|false"
        update(3)="true|false"
        optimi(4)stic-lock="true|false"
        unique(5)="true|false"
>

        <property ...../>
        <many-to-one .... />
        ........
</properties
>

1

name: El nombre lógico del agrupamiento. No es un nombre de propiedad.

2

insert: ¿Las columnas mapeadas aparacen en INSERTs SQL?

3

update: ¿Las columnas mapeadas aparacen en UPDATEs SQL?

4

optimistic-lock (opcional - por defecto es true): Especifica que las actualizaciones de estas propiedades requieren o no de la adquisición de un bloqueo optimista. Determina si debe ocurrir un incremento de versión cuando estas propiedades están desactualizadas.

5

unique (opcional - por defecto es false): Especifica que existe una restricción de unicidad sobre todas las columnas mapeadas del componente.

Por ejemplo, si tenemos el siguiente mapeo de <properties>:


<class name="Person">
    <id name="personNumber"/>

    ...
    <properties name="name"
            unique="true" update="false">
        <property name="firstName"/>
        <property name="initial"/>
        <property name="lastName"/>
    </properties>
</class
>

Puede que tenga alguna asociación de datos heredados que se refiera a esta clave única de la tabla de Person, en lugar de la clave principal:


<many-to-one name="person"
         class="Person" property-ref="name">
    <column name="firstName"/>
    <column name="initial"/>
    <column name="lastName"/>
</many-to-one
>

No recomendamos el uso de este tipo de cosas fuera del contexto del mapeo de datos heredados.

Se puede mapear cada subclase a su propia tabla. Esto se llama una estrategia de mapeo tabla-por-subclase. El estado heredado se recupera uniendo con la tabla de la superclase. Para hacer esto utilice elemento <joined-subclass>. Por ejemplo:

<joined-subclass
        name="(1)ClassName"
        table=(2)"tablename"
        proxy=(3)"ProxyInterface"
        lazy="(4)true|false"
        dynamic-update="true|false"
        dynamic-insert="true|false"
        schema="schema"
        catalog="catalog"
        extends="SuperclassName"
        persister="ClassName"
        subselect="SQL expression"
        entity-name="EntityName"
        node="element-name">

        <key .... >

        <property .... />
        .....
</joined-subclass
>

1

name: El nombre de clase completamente calificado de la subclase.

2

table: El nombre de tabla de la subclase.

3

proxy (opcional): Especifica una clase o interfaz que se debe utilizar para proxies de inicialización perezosa.

4

lazy (opcional, por defecto es true): El establecer lazy="false" desactiva el uso de la recuperación perezosa.

No se necesita una columna discriminadora para esta estrategia de mapeo. Sin embargo, cada subclase debe declarar una columna de tabla que tenga el identificador del objeto utilizando el elemento <key>. El mapeo mencionado al comienzo del capítulo se reescribiría así:


<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="eg">

        <class name="Cat" table="CATS">
                <id name="id" column="uid" type="long">
                        <generator class="hilo"/>
                </id>
                <property name="birthdate" type="date"/>
                <property name="color" not-null="true"/>
                <property name="sex" not-null="true"/>
                <property name="weight"/>
                <many-to-one name="mate"/>
                <set name="kittens">
                        <key column="MOTHER"/>
                        <one-to-many class="Cat"/>
                </set>
                <joined-subclass name="DomesticCat" table="DOMESTIC_CATS">
                    <key column="CAT"/>
                    <property name="name" type="string"/>
                </joined-subclass>
        </class>

        <class name="eg.Dog">
                <!-- mapping for Dog could go here -->
        </class>

</hibernate-mapping
>

For information about inheritance mappings see Capítulo 9, Mapeo de herencias.

Al utilizar el elemento <join>, es posible mapear las propiedades de una clase a varias tablas que tengan una relación uno-a-uno. Por ejemplo:

<join
        table=(1)"tablename"
        schema(2)="owner"
        catalo(3)g="catalog"
        fetch=(4)"join|select"
        invers(5)e="true|false"
        option(6)al="true|false">

        <key ... />

        <property ... />
        ...
</join
>

1

table: El nombre de la tabla unida.

2

schema (opcional): Sobrescribe el nombre del esquema especificado por el elemento raíz <hibernate-mapping>.

3

catalog (opcional): Sobrescribe el nombre del catálogo especificado por el elemento raíz <hibernate-mapping>.

4

fetch (opcional - por defecto es join): Si se establece como join, por defecto, Hibernate utilizará una unión interior (inner join) para recuperar un <join> definido por una clase o sus superclases. Utilizará una unión externa (outer join) para un <join> definido por una subclase. Si se establece como select, entonces Hibernate utilizará una selección secuencial para un <join> definido en una subclase. Esto se publicará sólamente si una fila representa una instancia de la subclase. Las uniones interiores todavía serán utilizadas para recuperar un <join> definido por la clase y sus superclases.

5

inverse (opcional - por defecto es false): De activarse, Hibernate no tratará de insertar o actualizar las propiedades definidas por esta unión.

6

optional (opcional - por defecto es false): De activarse, Hibernate insertará una fila sólo si las propiedades definidas por esta unión son no-nulas. Siempre utilizará una unión externa para recuperar las propiedades.

Por ejemplo, la información domiciliaria de una persona se puede mapear a una tabla separada, preservando a la vez la semántica de tipo de valor para todas las propiedades:


<class name="Person"
    table="PERSON">

    <id name="id" column="PERSON_ID"
>...</id>

    <join table="ADDRESS">
        <key column="ADDRESS_ID"/>
        <property name="address"/>
        <property name="zip"/>
        <property name="country"/>
    </join>
    ...

Con frecuencia, esta funcionalidad sólamente es útil para los modelos de datos heredados. Recomendamos menos tablas que clases y un modelo de dominio más detallado. Sin embargo, es útil para cambiar entre estrategias de mapeo de herencias en una misma jerarquía, como se explica más adelante.

Hasta ahora hemos visto el elemento <key> unas cuantas veces. Aparece en cualquier sitio en que el elemento padre de mapeo defina una unión a una nueva tabla que referencie la clave principal de la tabla original. También define la clave foránea en la tabla unida:

<key
        column(1)="columnname"
        on-del(2)ete="noaction|cascade"
        proper(3)ty-ref="propertyName"
        not-nu(4)ll="true|false"
        update(5)="true|false"
        unique(6)="true|false"
/>

1

column (opcional): El nombre de la columna de la clave foránea. Esto también se puede especificar por medio de uno o varios elementos anidados <column>.

2

on-delete (opcional - por defecto es noaction): Especifica si la restricción de clave foránea tiene el borrado en cascada activado a nivel de base de datos.

3

property-ref (opcional): Especifica que la clave foránea referencia columnas que no son la clave principal de la tabla original. Se proporciona para los datos heredados.

4

not-null (opcional): Especifica que las columnas de la clave foránea son no nulables. Esto se implica cuando la clave foránea también es parte de la clave principal.

5

update (opcional): Especifica que la clave foránea nunca se debe actualizar. Esto se implica cuando la clave foránea también es parte de la clave principal.

6

unique (opcional): Especifica que la clave foránea debe tener una restricción de . Esto se implica cuando la clave foránea también es la clave principal.

Para los sistemas en donde el rendimiento es importante, todas las claves deben ser definidas on-delete="cascade". Hibernate utiliza una restricción ON CASCADE DELETE a nivel de base de datos, en vez de muchas declaraciones DELETE individuales. Tenga en cuenta que esta funcionalidad evita la estrategia de bloqueo optimista normal de Hibernate para datos versionados.

Los atributos not-null y update son útiles al mapear una asociación uno a muchos unidireccional. Si mapea una unidireccional uno a muchos a una clave foránea no nulable, tiene que declarar la columna clave utilizando <key not-null="true">.

Los elementos de mapeo que acepten un atributo column aceptarán opcionalmente un subelemento <column>. De manera similar, <formula> es una alternativa al atributo formula. Por ejemplo:


<column
        name="column_name"
        length="N"
        precision="N"
        scale="N"
        not-null="true|false"
        unique="true|false"
        unique-key="multicolumn_unique_key_name"
        index="index_name"
        sql-type="sql_type_name"
        check="SQL expression"
        default="SQL expression"
        read="SQL expression"
        write="SQL expression"/>

<formula
>SQL expression</formula
>

La mayoría de los atributos en column proporcionan una manera de personalizar el DDL durante la generación del esquema automático. Los atributos read y write le permiten especificar SQL personalizado que Hibernate utilizará para acceder el valor de la columna. Para obtener mayor información sobre esto, consulte la discusión sobre expresiones de lectura y escritura de columnas.

Los elementos column y formula incluso se pueden combinar dentro del mismo mapeo de propiedad o asociación para expresar, por ejemplo, condiciones de unión exóticas.


<many-to-one name="homeAddress" class="Address"
        insert="false" update="false">
    <column name="person_id" not-null="true" length="10"/>
    <formula
>'MAILING'</formula>
</many-to-one
>

Hay un tipo más de mapeo de propiedad. El elemento de mapeo <any> define una asociación polimórfica a clases desde múltiples tablas. Este tipo de mapeo necesita más de una columna. La primera columna contiene el tipo de la entidad asociada. Las columnas restantes contienen el identificador. Es imposible especificar una restricción de clave foránea para este tipo de asociación. Esta no es la manera usual de mapear asociaciones polimórficas y sólamente debe usar esto en casos especiales. Por ejemplo, para registros de auditoría, datos de sesión de usuario, etc.

El atributo meta-type le permite especificar a la aplicación un tipo personalizado que mapea los valores de columnas de la base de datos a clases persistentes que tengan propiedades identificadoras del tipo especificado por id-type. Tiene que especificar el mapeo de valores del meta-tipo a nombres de clase.


<any name="being" id-type="long" meta-type="string">
    <meta-value value="TBL_ANIMAL" class="Animal"/>
    <meta-value value="TBL_HUMAN" class="Human"/>
    <meta-value value="TBL_ALIEN" class="Alien"/>
    <column name="table_name"/>
    <column name="id"/>
</any
>
<any
        name="(1)propertyName"
        id-typ(2)e="idtypename"
        meta-t(3)ype="metatypename"
        cascad(4)e="cascade_style"
        access(5)="field|property|ClassName"
        optimi(6)stic-lock="true|false"
>
        <meta-value ... />
        <meta-value ... />
        .....
        <column .... />
        <column .... />
        .....
</any
>

1

name: el nombre de la propiedad.

2

id-type: el tipo del identificador.

3

meta-type (opcional - por defecto es string): Cualquier tipo que se permita para un mapeo discriminador.

4

cascade (opcional- por defecto es none): el estilo de cascada.

5

access (opcional - por defecto es property): La estrategia que Hibernate utiliza para acceder al valor de la propiedad.

6

optimistic-lock (opcional - por defecto es true): Especifica si las actualizaciones de esta propiedad requieren o no de la adquisición del bloqueo optimista. Define si debe ocurrir un incremento de versión cuando esta propiedad está desactualizada.

En relación con el servicio de persistencia, los objetos a nivel de lenguaje Java se clasifican en dos grupos:

Una entidad existe independientemente de cualquier otro objeto que referencie a la entidad. Compare esto con el modelo habitual de Java en donde un objeto no referenciado es recolectado como basura. Las entidades deben ser guardadas y borradas explícitamente. Sin embargo, los grabados y borrados se pueden tratar en cascada desde una entidad padre a sus hijos. Esto es diferente al modelo de persistencia de objetos por alcance (ODMG) y corresponde más a cómo se utilizan habitualmente los objetos de aplicación en sistemas grandes. Las entidades soportan referencias circulares y compartidas, que también pueden ser versionadas.

El estado persistente de una entidad consta de las referencias a otras entidades e instancias de tipo valor. Los valores son primitivos: colecciones (no lo que está dentro de la colección), componentes y ciertos objetos inmutables. A diferencia de las entidades, los valores en particular las colecciones y los componentes, son persistidos y borrados por alcance. Como los objetos valor y primitivos son persistidos y borrados junto con sus entidades contenedoras, no se pueden versionar independientemente. Los valores no tienen identidad independiente, por lo que dos entidades o colleciones no los pueden compartir.

Hasta ahora, hemos estado utilizando el término "clase persistente" para referirnos a entidades. Continuaremos haciéndolo así. Sin embargo, no todas la clases con estado persistente definidas por el usuario son entidades. Un componente es una clase definida por el usuario con semántica de valor. Una propiedad Java de tipo java.lang.String también tiene semántica de valor. Dada esta definición, podemos decir que todos los tipo (clases) provistos por el JDK tienen una semántica de tipo valor en Java, mientras que los tipos definidos por el usuario se pueden mapear con semántica de tipo valor o de entidad. La desición corre por cuenta del desarrollador de la aplicación. Una clase entidad en un modelo de dominio son las referencias compartidas a una sola instancia de esa clase, mientras que la composición o agregación usualmente se traducen a un tipo de valor.

Volveremos a revisar ambos conceptos a lo largo de este manual de referencia.

EL desafío es mapear el sistema de tipos de Java ( la definición de entidades y tipos de valor de los desarrolladores al sistema de tipos de SQL/la base de datos. El puente entre ambos sistemas lo brinda Hibernate. Para las entidades utilizamos <class>, <subclass>, etc. Para los tipos de valor utilizamos <property>, <component>, etc, usualmente con un atributo type. El valor de este atributo es el nombre de un tipo de mapeo de Hibernate. Hibernate proporciona un rango de mapeos para tipos de valores del JDK estándar. Puede escribir sus propios mapeos de tipo e implementar sus estrategias de conversión personalizadas.

Todos los tipos incorporados de Hibernate soportan la semántica de nulos, a excepción de las colecciones.

Los tipos de mapeo básicos incorporados se pueden categorizar así:

integer, long, short, float, double, character, byte, boolean, yes_no, true_false

Mapeos de tipos de primitivos de Java o de clases de envoltura a los tipos de columna SQL (específica del vendedor). boolean, yes_no y true_false son codificaciones alternativas a boolean de Java o java.lang.Boolean.

string

Un mapeo del tipo java.lang.String a VARCHAR (u Oracle VAARCHAR2).

date, time, timestamp

Mapeos de tipo desde java.util.Date y sus subclases a tipos SQL DATE, TIME y TIMESTAMP (o equivalente).

calendar, calendar_date

Mapeos de tipo desde java.util.Date y tipos SQL TIMESTAMP y DATE (o equivalente).

big_decimal, big_integer

Mapeos de tipo desde java.math.BigDecimal y java.math.BigInteger a NUMERIC (o NUMBER de Oracle).

locale, timezone, currency

Mapeos de tipo desde java.util.Locale, java.util.TimeZone y java.util.Currency a VARCHAR (o VARCHAR2 de Oracle). Las instancias de Locale y Currency son mapeadas a sus códigos ISO. Las instancias de TimeZone son mapeadas a sus ID.

class

Un mapeo de tipo java.lang.Class a VARCHAR (o VARCHAR2 de Oracle). Una Class es mapeada a su nombre completamente calificado.

binary

Mapea arreglos de bytes a un tipo binario SQL apropiado.

text

Mapea cadenas largas de Java al tipo SQL CLOB o TEXT.

serializable

Mapea tipos serializables Java a un tipo binario SQL apropiado. También puede indicar el tipo serializable de Hibernate con el nombre de una clase o interfaz serializable Java que no sea por defecto un tipo básico.

clob, blob

Mapeos de tipo para las clases JDBC java.sql.Clob y java.sql.Blob. Estos tipos pueden ser inconvenientes para algunas aplicaciones, pues el objeto blob o clob no pueden ser reusados fuera de una transacción. Además, el soporte del controlador suele ser malo e inconsistente.

imm_date, imm_time, imm_timestamp, imm_calendar, imm_calendar_date, imm_serializable, imm_binary

Los mapeos de tipo para lo que usualmente se considera tipos Java mutables. Aquí es donde Hibernate realiza ciertas optimizaciones apropiadas sólamente para tipos Java inmutables y la aplicación trata el objeto como inmutable. Por ejemplo, no debe llamar Date.setTime() para una instancia mapeada como imm_timestamp. Para cambiar el valor de la propiedad y hacer que ese cambio sea persistente, la aplicación tiene que asignar un objeto nuevo, no idéntico, a la propiedad.

Los identificadores únicos de entidades y colecciones pueden ser de cualquier tipo básico excepto binary, blob y clob. Los identificadores compuestos también están permitidos, a continuación encontrará mayor información.

Los tipos de valor básicos tienen sus constantes Type correspondientes definidas en org.hibernate.Hibernate. Por ejemplo, Hibernate.STRING representa el tipo string.

Es relativamente fácil para los desarrolladores crear sus propios tipos de valor. Por ejemplo, puede que quiera persistir propiedades del tipo java.lang.BigInteger a columnas VARCHAR. Hibernate no provee un tipo incorporado para esto. Los tipos personalizados no están limitados a mapear una propiedad o elemento de colección a una sola columna de tabla. Así, por ejemplo, podría tener una propiedad Java getName()/setName() de tipo java.lang.String que es persistida a las columnas FIRST_NAME, INITIAL, SURNAME.

Para implementar un tipo personalizado, implemente org.hibernate.UserType o org.hibernate.CompositeUserType y declare las propiedades utilizando el nombre de clase completamente calificado del tipo. Revise org.hibernate.test.DoubleStringType para ver qué clases de cosas son posibles.


<property name="twoStrings" type="org.hibernate.test.DoubleStringType">
    <column name="first_string"/>
    <column name="second_string"/>
</property
>

Observe el uso de etiquetas <column> para mapear una propiedad a múltiples columnas.

Las interfaces CompositeUserType, EnhancedUserType, UserCollectionType, y UserVersionType brindan soporte para usos más especializados.

Incluso usted puede proporcionar parámetros a un UserType en el archivo de mapeo. Para hacer esto, su UserType tiene que implementar la interfaz org.hibernate.usertype.ParameterizedType. Para brindar parámetros a su tipo personalizado, puede utilizar el elemento <type> en sus archivos de mapeo.


<property name="priority">
    <type name="com.mycompany.usertypes.DefaultValueIntegerType">
        <param name="default"
>0</param>
    </type>
</property
>

Ahora el UserType puede recuperar el valor del parámetro denominado default del objeto Properties que se le pasa.

Si utiliza cierto UserType muy frecuentemente, puede ser útil el definir un nombre más corto para este. Puede hacer esto utilizando el elemento <typedef>. Los typedefs asignan un nombre a un tipo personalizado y también pueden contener una lista de valores predeterminados de parámetros si el tipo se encuentra parametrizado.


<typedef class="com.mycompany.usertypes.DefaultValueIntegerType" name="default_zero">
    <param name="default"
>0</param>
</typedef
>

<property name="priority" type="default_zero"/>

También es posible sobrescribir los parámetros provistos en un typedef sobre una base de caso por caso utilizando parámetros de tipo en el mapeo de la propiedad.

Aunque el amplio espectro de tipos incorporados y de soporte para los componentes de Hibernate significa que necesitará usar un tipo personalizado muy raramente, se considera como una buena práctica el utilizar tipos personalizados para clases no-entidades que aparezcan frecuentemente en su aplicación. Por ejemplo, una clase MonetaryAmount es una buena candidata para un CompositeUserType, incluso cuando puede ser fácilmente mapeada como un componente. Un razón para esto es la abstracción. Con un tipo personalizado, sus documentos de mapeo estarán protegidos contra posibles cambios futuros en la forma de representar valores monetarios.

Es posible proporcionar más de un mapeo para una clase persistente en particular. En este caso usted debe especificar un nombre de entidad para aclarar entre las instancias de las dos entidades mapeadas. Por defecto, el nombre de la entidad es el mismo que el nombre de la clase. Hibernate le deja especificar el nombre de entidad al trabajar con objetos persistentes, al escribir consultas, o al mapear asociaciones a la entidad mencionada.

<class name="Contract" table="Contracts"
        entity-name="CurrentContract">
    ...
    <set name="history" inverse="true"
            order-by="effectiveEndDate desc">
        <key column="currentContractId"/>
        <one-to-many entity-name="HistoricalContract"/>
    </set>
</class>

<class name="Contract" table="ContractHistory"
        entity-name="HistoricalContract">
    ...
    <many-to-one name="currentContract"
            column="currentContractId"
            entity-name="CurrentContract"/>
</class
>

Las asociaciones ahora se especifican utilizando entity-name en lugar de class.

Puede forzar a Hibernate a que utilice comillas con un identificador en el SQL generado encerrando el nombre de tabla o de columna entre comillas sencillas en el documento de mapeo. Hibernate utilizará el estilo de comillas para el Dialect SQL. Usualmente comillas dobles, a excepción de corchetes para SQL Server y comillas sencillas para MySQL.


<class name="LineItem" table="`Line Item`">
    <id name="id" column="`Item Id`"/><generator class="assigned"/></id>
    <property name="itemNumber" column="`Item #`"/>
    ...
</class
>

XML no es para todo el mundo, así que hay algunas formas opcionales de definir metadatos de mapeo O/R en Hibernate.

Muchos usuarios de Hibernate prefieren incluir la información de mapeo directamente en el código fuente usando las @hibernate.tags XDoclet. No abordaremos este enfoque en este manual de referencia ya que se considera como parte de XDoclet. Sin embargo, incluímos el siguiente ejemplo de la clase Cat con los mapeos XDoclet:

package eg;

import java.util.Set;
import java.util.Date;
/**
 * @hibernate.class
 *  table="CATS"
 */
public class Cat {
    private Long id; // identifier
    private Date birthdate;
    private Cat mother;
    private Set kittens
    private Color color;
    private char sex;
    private float weight;
    /*
     * @hibernate.id
     *  generator-class="native"
     *  column="CAT_ID"
     */
    public Long getId() {
        return id;
    }
    private void setId(Long id) {
        this.id=id;
    }
    /**
     * @hibernate.many-to-one
     *  column="PARENT_ID"
     */
    public Cat getMother() {
        return mother;
    }
    void setMother(Cat mother) {
        this.mother = mother;
    }
    /**
     * @hibernate.property
     *  column="BIRTH_DATE"
     */
    public Date getBirthdate() {
        return birthdate;
    }
    void setBirthdate(Date date) {
        birthdate = date;
    }
    /**
     * @hibernate.property
     *  column="WEIGHT"
     */
    public float getWeight() {
        return weight;
    }
    void setWeight(float weight) {
        this.weight = weight;
    }
    /**
     * @hibernate.property
     *  column="COLOR"
     *  not-null="true"
     */
    public Color getColor() {
        return color;
    }
    void setColor(Color color) {
        this.color = color;
    }
    /**
     * @hibernate.set
     *  inverse="true"
     *  order-by="BIRTH_DATE"
     * @hibernate.collection-key
     *  column="PARENT_ID"
     * @hibernate.collection-one-to-many
     */
    public Set getKittens() {
        return kittens;
    }
    void setKittens(Set kittens) {
        this.kittens = kittens;
    }
    // addKitten not needed by Hibernate
    public void addKitten(Cat kitten) {
        kittens.add(kitten);
    }
    /**
     * @hibernate.property
     *  column="SEX"
     *  not-null="true"
     *  update="false"
     */
    public char getSex() {
        return sex;
    }
    void setSex(char sex) {
        this.sex=sex;
    }
}

Para obtener más ejemplos de XDoclet e Hibernate consulte el sitio web de Hibernate.

JDK 5.0 introdujo anotaciones del estilo XDoclet a nivel del lenguaje con chequeo seguro de tipos en tiempo de compilación. Este mecanismo es más potente que las anotaciones XDoclet y es mejor soportado por herramientas e IDEs. IntelliJ IDEA, por ejemplo, soporta auto-completación además de resalte de sintaxis de las anotaciones JDK 5.0. La nueva revisión de la especificación de EJB (JSR-220) utiliza anotaciones JDK 5.0 como el mecanismo principal de metadatos para beans de entidad. Hibernate3 implementa el EntityManager del JSR-220 (la API de persistencia). El soporte para metadatos de mapeo está disponible por medio del paquete Anotaciones de Hibernate, como una descarga separada. Tanto los metadatos de EJB3 (JSR-220) como de Hibernate3 se encuentran soportados.

Este es un ejemplo de una clase POJO anotada como un bean de entidad EJB:

@Entity(access = AccessType.FIELD)

public class Customer implements Serializable {
    @Id;
    Long id;
    String firstName;
    String lastName;
    Date birthday;
    @Transient
    Integer age;
    @Embedded
    private Address homeAddress;
    @OneToMany(cascade=CascadeType.ALL)
    @JoinColumn(name="CUSTOMER_ID")
    Set<Order
> orders;
    // Getter/setter and business methods
}

Las propiedades generadas son propiedades cuyos valores son generados por la base de datos. Usualmente, las aplicaciones de Hibernate necesitaban refrescar los objetos que contenian cualquier propiedad para la cual la base de datos generará valores. Sin embargo, el marcar propiedades como generadas deja que la aplicación delegue esta responsabilidad a Hibernate. Cuando Hibernate emite un INSERT or UPDATE SQL para una entidad la cual ha definido propiedades generadas, inmediatamente emite un select para recuperar los valores generados.

Las propiedades marcadas como generadas tienen que ser además no insertables y no actualizables. Sólamente las versiones, sellos de fecha, y propiedades simples se pueden marcar como generadas.

never (por defecto): el valor dado de la propiedad no es generado dentro de la base de datos.

insert: el valor dado de la propiedad es generado en insert, pero no es regenerado en las actualizaciones posteriores. Las propiedades como fecha-creada (created-date) se encuentran dentro de esta categoría. Aunque las propiedades versión y sello de fecha se pueden marcar como generadas, esta opción no se encuentra disponible.

always: el valor de la propiedad es generado tanto en insert como en update.

Hibernate allows you to customize the SQL it uses to read and write the values of columns mapped to simple properties. For example, if your database provides a set of data encryption functions, you can invoke them for individual columns like this:

<!-- XML : generated by JHighlight v1.0 (http://jhighlight.dev.java.net) -->
<span class="xml_tag_symbols">&lt;</span><span class="xml_tag_name">property</span><span class="xml_plain">&nbsp;</span><span class="xml_attribute_name">name</span><span class="xml_tag_symbols">=</span><span class="xml_attribute_value">&quot;creditCardNumber&quot;</span><span class="xml_tag_symbols">&gt;</span><span class="xml_plain"></span><br />
<span class="xml_plain">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="xml_tag_symbols">&lt;</span><span class="xml_tag_name">column</span><span class="xml_plain">&nbsp;</span><br />
<span class="xml_plain">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="xml_attribute_name">name</span><span class="xml_tag_symbols">=</span><span class="xml_attribute_value">&quot;credit_card_num&quot;</span><span class="xml_plain"></span><br />
<span class="xml_plain">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="xml_attribute_name">read</span><span class="xml_tag_symbols">=</span><span class="xml_attribute_value">&quot;decrypt(credit_card_num)&quot;</span><span class="xml_plain"></span><br />
<span class="xml_plain">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="xml_attribute_name">write</span><span class="xml_tag_symbols">=</span><span class="xml_attribute_value">&quot;encrypt(?)&quot;</span><span class="xml_tag_symbols">/&gt;</span><span class="xml_plain"></span><br />
<span class="xml_tag_symbols">&lt;/</span><span class="xml_tag_name">property</span><span class="xml_plain"></span><br />
<span class="xml_tag_symbols">&gt;</span><span class="xml_plain"></span><br />

Hibernate aplica las expresiones personalizadas de manera automática cuando la propiedad se referencia en una petición. Esta funcionalidad es similar a una propiedad derivada formula con dos diferencias:

  • Esta propiedad está respaldada por una o más columnas que se exportan como parte de la generación automática del esquema.

  • La propiedad es de lectura y escritura no de sólo lectura.

Si se especifica la expresión write debe contener exactamente un parémetro de sustitución '?' para el valor.

Los objetos de bases de datos auxiliares permiten la creación - CREATE - y eliminación - DROP - de objetos de bases de datos arbitrarios. Junto con las herramientas de evolución del esquema de Hibernate, tienen la habilidad de definir de manera completa el esquema de un usuario dentro de los archivos de mapeo de Hibernate. Aunque están diseñados específicamente para crear y eliminar cosas como disparadores - triggers- o procedimientos almacenados, realmente cualquier comando SQL se puede ejecutar por medio de un método java.sql.Statement.execute() aquí es válido (por ejemplo, ALTERs, INSERTS, etc). Básicamente, hay dos modos para definir objetos de bases de datos auxiliares:

El primer modo es para numerar explícitamente los comandos CREATE y DROP en el archivo de mapeo:


<hibernate-mapping>
    ...
    <database-object>
        <create
>CREATE TRIGGER my_trigger ...</create>
        <drop
>DROP TRIGGER my_trigger</drop>
    </database-object>
</hibernate-mapping
>

El segundo modo es para proporcionar una clase personalizada que construye los comandos CREATE y DROP. Esta clase personalizada tiene que implementar la interfaz org.hibernate.mapping.AuxiliaryDatabaseObject.


<hibernate-mapping>
    ...
    <database-object>
        <definition class="MyTriggerDefinition"/>
    </database-object>
</hibernate-mapping
>

Adicionalmente, estos objetos de la base de datos se pueden incluir de manera opcional de forma que aplique sólamente cuando se utilicen ciertos dialectos.


<hibernate-mapping>
    ...
    <database-object>
        <definition class="MyTriggerDefinition"/>
        <dialect-scope name="org.hibernate.dialect.Oracle9iDialect"/>
        <dialect-scope name="org.hibernate.dialect.Oracle10gDialect"/>
    </database-object>
</hibernate-mapping
>