JPA entities - EJB 3 in Action - page 346

of the email property is “email,” by default JPA assumes an EMAIL column exists in the
USERS table. Because of this convention-over-configuration preference, if all of your ob-
ject's property names match the name of the column they're persisted to, then you won't
need to use the @Column attribute at all.
Listing 9.3 shows the @Column annotation in its simplest form. The next listing shows the
other attributes of the annotation.
Listing 9.4. @Column attributes
@Target ({ METHOD, FIELD })
@Retention(RUNTIME)
public @interface Column {
String name() default "";
boolean unique() default false;
boolean nullable() default true;
boolean insertable() default true;
boolean updatable() default true;
String columnDefinition() default "";
String table() default "";
int length() default 255;
int precision() default 0;
int scale() default 0;
}
As you can see, there's a lot more to @Column , but these attributes aren't commonly used.
The insertable and updatable attributes are most useful. If insertable is false,
JPA won't include the Java object property in the SQL INSERT statement when persisting
new data. Similarly, if updatable is false, JPA won't include the property in the SQL
UPDATE statement when updating existing data. Why wouldn't you want to persist data?
There can be any number of reasons, but a common one is that the data is generated by the
database itself, usually through some kind of trigger. A table that uses a database-generated
primary key is a good example.
The rest of the parameters ( unique , nullable , length , precision , scale ,
table , and columnDefinition ) are used by the persistence provider's vendor-spe-
cific automatic schema generation to create the tables in the database if they don't already
exist. As discussed in section 9.3.2 , this is almost never a good idea, so we'll leave you to
further explore these attributes on your own.