What properties does @Column columnDefinition make redundant?

Solution 1:

My Answer: All of the following should be overridden (i.e. describe them all within columndefinition, if appropriate):

• length
• precision
• scale
• nullable
• unique

i.e. the column DDL will consist of: name + columndefinition and nothing else.

Rationale follows.

1. Annotation containing the word "Column" or "Table" is purely physical - properties only used to control DDL/DML against database.

2. Other annotation purely logical - properties used in-memory in java to control JPA processing.

3. That's why sometimes it appears the optionality/nullability is set twice - once via @Basic(...,optional=true) and once via @Column(...,nullable=true). Former says attribute/association can be null in the JPA object model (in-memory), at flush time; latter says DB column can be null. Usually you'd want them set the same - but not always, depending on how the DB tables are setup and reused.

In your example, length and nullable properties are overridden and redundant.

So, when specifying columnDefinition, what other properties of @Column are made redundant?

1. In JPA Spec & javadoc:

   • columnDefinition definition: The SQL fragment that is used when generating the DDL for the column.

   • columnDefinition default: Generated SQL to create a column of the inferred type.

   • The following examples are provided:

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

   • And, err..., that's it really. :-$ ?!

   Does columnDefinition override other properties provided in the same annotation?

   The javadoc and JPA spec don't explicity address this - spec's not giving great protection. To be 100% sure, test with your chosen implementation.

2. The following can be safely implied from examples provided in the JPA spec

   • name & table can be used in conjunction with columnDefinition, neither are overridden
   • nullable is overridden/made redundant by columnDefinition

3. The following can be fairly safely implied from the "logic of the situation" (did I just say that?? :-P ):

   • length, precision, scale are overridden/made redundant by the columnDefinition - they are integral to the type
   • insertable and updateable are provided separately and never included in columnDefinition, because they control SQL generation in-memory, before it is emmitted to the database.

4. That leaves just the "unique" property. It's similar to nullable - extends/qualifies the type definition, so should be treated integral to type definition. i.e. should be overridden.

Test My Answer For columns "A" & "B", respectively:

  @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"

• confirm generated table has correct type/nullability/uniqueness
• optionally, do JPA insert & update: former should include column A, latter column B

Solution 2:

columnDefinition will override the sql DDL generated by hibernate for this particular column, it is non portable and depends on what database you are using. You can use it to specify nullable, length, precision, scale... ect.