Index  •  Intro  •  WSDL  •  Apache Ant  •  DTD's for XML  •  ObJectRelationalBridge  •  Hibernate  •  Gallery  •  FAQ  •  Help  •  JavaDoc  •  Download

Hibernate Configuration  •  Object Relational Impedance Mismatch

Introduction
Hibernate {1} and Apache ObJect Relational Bridge (OJB) {2} are a leading object-relational mapping solution widely used in Java community. The main goal of these tools is to eliminate 95% of all programming tasks related to data persistence. This goal has already been realized in many software development team that fully rely on Hibernate and OJB and do not have a single line of SQL code written by hand. In addition to hiding database access details, more importantly, Hibernate and OJB encourage object-oriented view of artifacts stored in the database. They encourage object-oriented design over database-centric software design. Despite its great powers object-relational mapping tools can be misused and greatly misunderstood. It is quite easy to use Hibernate and OJB in SQL-like relational way and miss all the benefits of object-oriented design. On top of this impedance mismatch, the runtime consequences of using object-relational mapping and persistence by reachability can be extremely complicated. You might no know it yourself, but just trust those of us that do.

Databases have normalization, objects have refactoring
But how to improve schemas? There are certain approaches for improving databases, database normalization for example {3}. Similarly, numerous approaches exist in the pure object-oriented world, refactoring {4} for example. But how to make database tables look more like objects, and less like database tables? Hibernate and OJB can hide database access details. What they can't hide are the differences in usage of databases and objects {5}.

A major goal of Hibernate 3.0 was better support for "crazy" legacy data models. The Hibernate team added excellent support for most legacy and even broken data models. However, even in their FAQ, the team encourages all users to clean up and improve their schemas whenever possible to object-like. But it is not obvious what exactly to improve.

Databases engines are robust, virtual machines are fragile
Most importantly databases are more robust and tolerate more abuse compared to virtual machines. Objects run in the virtual machines where one can have fatal errors like deadlocks or infinite loops. While database queries run in the database engine that guarantees that no fatal errors will occur. If SQL query fails - not a big deal, run it again. If virtual machine crashes - downtime, the business loses money.

Database can join anything to anything, objects can only use declared relations
Not less importantly, databases are more flexible from the data-access perspective. Objects allow only navigation to a well known set of other objects via object references. While database queries can create any number and any kind of relations between any rows with joins. For example, if an object instance A has no references to an object instance B there is no way in the object-oriented world to navigate from A to B, even if B has a reference to A. In the database world you can join them together using some inverse foreign key.

Databases allow you to join anything with anything, but object-oriented systems do not. Object-oriented systems require you to design most of if not all of relations upfront.

Databases are updated as sets, objects are updated as graphs
When rows in database need to change they are modified one-by-one or in sets. When object graphs are traversed and object are modified it is quite difficult to keep track of what objects will be written to database.

Let's review some of the object versioning rules that are at play when object graph is materialized and persisted in OJB. The Apache OJB, while conducting persistance by reachability, supports optimistic locking implemented via object versioning. You can enable this feature by adding locking="true" and update-lock="true" to <field-descriptor> mapping file schema element. At the same time there is a specific setting called auto-update="none|link|object" in the Apache OJB <reference-descriptor> schema element. If you select "object", the OJB automatically inserts or updates objects when an object that references them is inserted or updated.

• If a referenced object is materialized before the referring object is updated or inserted, the referenced object will sometimes be updated too. If nothing is explicitly changed in the referenced object, its version field will be incremented. OJB decides whether to update referenced objects or not based on the following rules.

• If a referenced object is not materialized before the referring object is updated or inserted, the referenced object will not be updated and it's version field will not change.

• If a referenced collection is materialized before the referring object is updated or inserted, elements of the referenced collection will not be updated. If, however, every element of the referenced collection is materialized, they will be updated when the object referring to their collection is updated.

All updates propagate throughout the object graph according to the rules above: if a referenced object is materialized, it will be updated; if every element of the referenced collection is materialized, all of them will be updated, and so on for as many levels as you materialized.

To avoid unnecessary updates, especially with collection references, you can split your transaction in two parts, where you materialize references to gather required data or make changes in one transaction, and update or insert an object referring to a graph of objects or a collection in the other transaction.

References

1. Hibernate
2. Apache ObJectRelationalBridge
3. http://en.wikipedia.org/wiki/Database_normalization
4. Martin Fowler: Refactoring.
5. http://www.agiledata.org/essays/impedanceMismatch.html

Index  •  Intro  •  WSDL  •  Apache Ant  •  DTD's for XML  •  ObJectRelationalBridge  •  Hibernate  •  Gallery  •  FAQ  •  Help  •  JavaDoc  •  Download

Hibernate Configuration  •  Object Relational Impedance Mismatch