java - false - ¿Qué propiedades hace @Column columnDefinition hacer redundante?

java @lob

Question

A menudo especifico mis anotaciones de @Column como esta:

@Column(columnDefinition="character varying (100) not null",length=100,nullable=false)

Como puede ver, especifico la length y se pueden columnDefinition a pesar de que columnDefinition ya los especifica. Eso es porque no sé dónde / cuándo se usan estos valores exactamente.

Entonces, cuando se especifica columnDefinition , ¿qué otras propiedades de @Column se @Column redundantes?

Si es importante, uso Hibernate y PostgreSQL

Answer 1

Mi respuesta: se debe anular todo lo siguiente (es decir, describirlos todos dentro de la columndefinition , si corresponde):

• length
• precision
• scale
• nullable
• unique

es decir, la columna DDL consistirá en: name + columndefinition y nada más .

La razón sigue.

1. La anotación que contiene la palabra "Columna" o "Tabla" es puramente física; las propiedades solo se usan para controlar DDL / DML contra la base de datos.

2. Otra anotación puramente lógica: propiedades utilizadas en la memoria en java para controlar el procesamiento de JPA.

3. Es por eso que a veces parece que la opción / nulability se establece dos veces: una vez a través de @Basic(...,optional=true) y una vez a través de @Column(...,nullable=true) . El ex dice que el atributo / asociación puede ser nulo en el modelo de objetos JPA (en memoria), en el momento del vaciado; el último dice que la columna DB puede ser nula. Por lo general, desearía que se configuraran de la misma manera, pero no siempre , dependiendo de cómo se configuran y reutilizan las tablas de BD.

En su ejemplo, las propiedades de longitud y anulables se anulan y son redundantes.

Entonces, cuando se especifica columnDefinition, ¿qué otras propiedades de @Column se vuelven redundantes?

1. En JPA Spec & javadoc:

   • Definición de columnDefinition : el fragmento de SQL que se utiliza al generar el DDL para la columna.

   • predeterminado de columnDefinition : SQL generado para crear una columna del tipo inferido.

   • Se proporcionan los siguientes ejemplos:

     @Column(name="DESC", columnDefinition="CLOB NOT NULL", table="EMP_DETAIL")
     @Column(name="EMP_PIC", columnDefinition="BLOB NOT NULL")

   • Y, err ..., eso es realmente. ps

   ¿ColumnDefinition reemplaza otras propiedades proporcionadas en la misma anotación?

   Las especificaciones javadoc y JPA no abordan explícitamente esto: las especificaciones no ofrecen una gran protección. Para estar 100% seguro, prueba con la implementación elegida.

2. Lo siguiente puede estar implícito de forma segura a partir de ejemplos proporcionados en la especificación JPA

   • name y table se pueden usar junto con columnDefinition , ninguno de los columnDefinition se reemplaza
   • nullable es anulado / hecho redundante por columnDefinition

3. Lo siguiente puede implicarse de manera bastante segura a partir de la "lógica de la situación" (¿acabo de decir eso? :-P):

   • length , precision , scale son anuladas / hechas redundantes por el columnDefinition - son integrales al tipo
   • insertable y updateable se proporcionan por separado y nunca se incluyen en columnDefinition , ya que controlan la generación de SQL en la memoria, antes de que se emita en la base de datos.

4. Eso deja solo la propiedad " unique ". Es similar a anulables: amplía / califica la definición de tipo, por lo que debe tratarse como integral a la definición de tipo. es decir, debe ser anulado.

Pruebe mi respuesta para las columnas "A" y "B", respectivamente:

 @Column(name="...", table="...", insertable=true, updateable=false,
columndefinition="NUMBER(5,2) NOT NULL UNIQUE"
@Column(name="...", table="...", insertable=false, updateable=true,
columndefinition="NVARCHAR2(100) NULL"

• confirmar que la tabla generada tiene el tipo / nulabilidad / unicidad correctos
• Opcionalmente, haga la inserción y actualización de JPA: el anterior debe incluir la columna A, la última columna B

Answer 2

columnDefinition anulará el DDL sql generado por hibernación para esta columna en particular, no es portátil y depende de la base de datos que esté utilizando. Puede usarlo para especificar nullable, longitud, precisión, escala ... ect.