Hello,

we have an application running on an oodb which we intend to port to run on a rdb. Our application relies on transparent access and on persistance per reachability. we have checked out toplink but are having problems with the unit-of-work concept which requires to "check-in" all objects we intend to update. our application functions roughly according to the following pattern:



we do not want to change the application (years work) just the accessLayer and the db and transaction frameworks.

with toplink we see no way to do this. either we put the collection into the unit-of-work or we have to call the unit-of-work in the application or object.update method.

with odmg we have a dirty flag so during commit it is easy to find the updated objects. toplink will have to iterate through all the objects in the unit-of-work to find the dirty ones to commit.

i wonder if hibernate has a better solution. how does this function with hibernate ?

Ron

Hibernate is essentially a very similar model to ODMG. We even provide an ODMG compatibility layer, though there are two caveats with it

* not many people have ever used it, so you might find yourself making little improvements and or changes
* The query language is really HQL, which actually implements "most" of ODMG OQL but does have a couple of little differences


In particular
* no method calls
* you must use the relational "IS NULL" operator instead of "= null"
* we use "select new Foo()" instead of the ODMG struct notation
* we do not support the "pure functional" syntax
* the HQL elements() function is introduced in some places
* we dont support typecasts yet

So, perhaps many of your OQL queries might continue to work, with only these changes

OTOH, we have the following extensions
* support for explicit ANSI-SQL-style JOIN syntax, which allows outer joins etc (in HQL this is much preferred to the ODMG style comma)
* the FETCH keyword
* support for calling SQL functions

etc.

It would be really interesting to see someone try to port an existing application from an ODB to the Hibernate ODMG layer.

Actually, I may have misunderstood your question. If you are asking about the performance impact of retrieving 1 million objects in a transaction, then no, this will not be efficient in Hibernate or any other ORM tool. Its simply not the way to do things when you have a relational database underneath.

This is independant of TopLinks checkin/checkout model (which is different form Hibernate).

Gavin,

Thank you for the prompt reply.
Since we are not using OQL but simple queries such as "select * from class"
I do not think that we will have problems on this side.

Where we may have problems is that if we have read in many objects into the JVM (to display them on the gui) and then change just a few the ORM should be efficient enough, eg it should not have to check all persistant objects in the JVM to see which have changed before deciding which should be updated.

The second requirement is to be able to access the objects after commit. we commit so that objects are not locked in the database.

The third requirement is the ability to use trigers to be able to automaticly update objects in the JVM in case these have been changed in the DB by another user.

Regards

Ron

You should not load a million objects in a transaction. This is simply too nonperformant on any database. However, it is not a Hibernate related problem because:

(1) The work done during dirty checking is MUCH, much less that the work done in loading the objects from the database in the first place (approx 5% overhead or less, in typical cases).
(2) There are ways to avoid the dirty check in Hibernate (evict(), clear(), setting the FlushMode, etc).

Hibernate dirty checking is amazingly efficient. Try it.




No problem. You can even reuse them in a new transaction.



It is possible to evict objects from the JVM-level cache or the Session-level cache at any time.

OTOH, a much better solution is to just disable the JVM-level cache for those classes which are updated outside of the application. This is a best-practice solution in ORM.