Java persistence with hibernate concept 5 -- Class mapping options

-------------------------------------------------------------------------------------------------------------

Class mapping options

If you check the <hibernate-mapping> and <class> elements in the DTD (or the
reference documentation), you’ll find a few options we haven’t discussed so far:
■ Dynamic generation of CRUD SQL statements
■ Entity mutability control
■ Naming of entities for querying
■ Mapping package names
■ Quoting keywords and reserved database identifiers
■ Implementing database naming conventions

-------------------------------------------------------------------------------------------------------------

Dynamic SQL generation

By default, Hibernate creates SQL statements for each persistent class on startup.
These statements are simple create, read, update, and delete operations for reading
a single row, deleting a row, and so on.
How can Hibernate create an UPDATE statement on startup? After all, the columns
to be updated aren’t known at this time. The answer is that the generated
SQL statement updates all columns, and if the value of a particular column isn’t
modified, the statement sets it to its old value.
In some situations, such as a legacy table with hundreds of columns where the
SQL statements will be large for even the simplest operations (say, only one column
needs updating), you have to turn off this startup SQL generation and switch
to dynamic statements generated at runtime. An extremely large number of entities
can also impact startup time, because Hibernate has to generate all SQL statements
for CRUD upfront. Memory consumption for this query statement cache
will also be high if a dozen statements must be cached for thousands of entities
(this isn’t an issue, usually).
Two attributes for disabling CRUD SQL generation on startup are available on
the <class> mapping element:

<class name="Item"
           dynamic-insert="true"
           dynamic-update="true">
...
</class>

The dynamic-insert attribute tells Hibernate whether to include null property
values in an SQL INSERT, and the dynamic-update attribute tells Hibernate
whether to include unmodified properties in the SQL UPDATE.
If you’re using JDK 5.0 annotation mappings, you need a native Hibernate
annotation to enable dynamic SQL generation:

@Entity
@org.hibernate.annotations.Entity(
dynamicInsert = true, dynamicUpdate = true
)
public class Item { ...

The second @Entity annotation from the Hibernate package extends the JPA
annotation with additional options, including dynamicInsert and dynamicUpdate.
Sometimes you can avoid generating any UPDATE statement, if the persistent
class is mapped immutable.

------------------------------------------------------------------------------------------------

Making an entity immutable

Instances of a particular class may be immutable. For example, in CaveatEmptor,
a Bid made for an item is immutable. Hence, no UPDATE statement ever needs to
be executed on the BID table. Hibernate can also make a few other optimizations,
such as avoiding dirty checking, if you map an immutable class with the mutable
attribute set to false:

<hibernate-mapping default-access="field">
    <class name="Bid" mutable="false">
    ...
    </class>
</hibernate-mapping>

A POJO is immutable if no public setter methods for any properties of the class are
exposed—all values are set in the constructor. Instead of private setter methods,
you often prefer direct field access by Hibernate for immutable persistent classes,
so you don’t have to write useless accessor methods. You can map an immutable
entity using annotations:

@Entity
@org.hibernate.annotations.Entity(mutable = false)
@org.hibernate.annotations.AccessType("field")
public class Bid { ...

Again, the native Hibernate @Entity annotation extends the JPA annotation with
additional options. We have also shown the Hibernate extension annotation
@AccessType here—this is an annotation you’ll rarely use. As explained earlier,
the default access strategy for a particular entity class is implicit from the position
of the mandatory @Id property. However, you can use @AccessType to force a
more fine-grained strategy; it can be placed on class declarations (as in the preceding
example) or even on particular fields or accessor methods.
Let’s have a quick look at another issue, the naming of entities for queries.