-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Multiple column versionning
PostPosted: Wed Sep 10, 2008 7:04 am 
Newbie

Joined: Wed Sep 10, 2008 6:29 am
Posts: 1
Dear hibernate gurus,

I'm having severe difficulties to handle multiple-columns version checking (optimistic locking) with hibernate version 3.2.

I'm working on a java application using hibernate to access a legacy database used by several legacy systems.
The legacy systems use 2 columns for optimistic locking related checkings, a first one which is the DATE of the change and a second which is the TIME (hh:mm:ss) of the change.

I know how that seems but I can't have 800 legacy tables to change their structure just because I ask for it ... So I have to deal with this 1 second precision version checking :-(

Anyway that's not the subject here ...

So I ended up with the following definition in my mapping file:


Code:

    <typedef name="JTVersion" class="xxx.JTVersionType" />   

    ...

    <version name="version" type="JTVersion">
        <column name="DATE_CHG" />
        <column name="TIME_CHG" />
    </version>




I obviously defined the JTVersionType as

Code:
public class JTVersionType implements VersionType, AbstractComponentType, Comparator<Object> {

...



The implementation was really simple, easy and straigth forward.


Now, unfortunately, this just CAN'T work :-(

Hibernate just can't handle multiple-columns version checking at the moment

And this is why :

Hibernate uses the version property as an additional column in the where clause of the update statement for optimistic locking purpose.

The problem is that there can only be, no matter what I try, ONE SINGLE and only ONE version column, never more.

Have a look at the class
Quote:
org.hibernate.persister.entity.AbstractEntityPersister

line 118 :

Code:
    private final String versionColumnName;


Only ONE single column name is possible ...

This is confirmed everywhere :

Quote:
org.hibernate.persister.entity.AbstractEntityPersister

line 474 - 481 :

Code:
      // VERSION

      if ( persistentClass.isVersioned() ) {
         versionColumnName = ( ( Column ) persistentClass.getVersion().getColumnIterator().next() ).getQuotedName( factory.getDialect() );
      }
      else {
         versionColumnName = null;
      }


Look at the code above : it uses "getColumnIterator().next()" . Hence only the first column in my mapping definition can be used by the where clause of the update statement.

And so on ...

Quote:
org.hibernate.sql.Update

line 22 :

Code:
private String versionColumnName;


One single column is possible for version checking, never more, everywhere.

It seems that I am not the first one who has that problem :

http://opensource.atlassian.com/projects/hibernate/browse/HHH-438

Notice that the UserVersionType interface is not helpful at all when it's about multiple-columns version checking.

So what am I missing ?

Is there any hidden mecanism I haven't seen which I could use for implementing multiple-columns version checking ?

Is there any plan to support this feature sooner or later within hibernate ?

Should I work on the required changes to support multiple columns version checking, would you be interested in integrating it into the hibernate sources ?

Hey many thanks in advance for your answers guys :-)


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.