Hi All,

I wonder if components are always seen as immutable objects. I mean...

I have the persistent object (po.User) as declared in the following mapping file. The object has one component (po.UserName).

The problem is that I cannot get the object marked as dirty with the code...

[i]// initialize Session and Transaction
po.User user = ... // user is a persistent object
user.getName().setSurname("change me");
// Is user marked as dirty?
// commit transaction, flush and close Session[/i]
...while it's all right with the code...

[i]// initialize Session and Transaction
po.User user = ... // user is a persistent object
po.UserName newUserName = ... // create a new UserName object
user.setName(newUserName);
// user is marked as dirty
// commit transaction, flush and close Session[/i]

I'm using Hibernate 2.1 . I think the cause of this behaviour (desired or not) is in the class net.sf.hibernate.type.ComponentType

[i]public boolean isDirty(Object x, Object y, SessionImplementor session) throws HibernateException {
if (x==y) return false; // <---------
if (x==null || y==null) return true;
for ( int i=0; i<getters.length; i++ ) {
if ( propertyTypes[i].isDirty( getters[i].get(x), getters[i].get(y), session ) ) return true;
}
return false;
}[/i]

Thanks.

[i]<hibernate-mapping>
<class name="po.User" table="po.User">
<id access="field" name="id" type="string">
<column name="CAT_ID" not-null="true"/>
<generator class="uuid.hex" />
</id>
<version name="version" type="integer" unsaved-value="null"/>
<component name="name" class="po.UserName">
<property access="field" name="title">
<column name="TITLE" not-null="true"/>
</property>
<property access="field" name="name">
<column name="NAME" not-null="true"/>
</property>
<property access="field" name="surname">
<column name="SURNAME" not-null="true"/>
</property>
</component>
...
</class>
</hibernate-mapping>[/i]

You are mistaken. Dirty checking of components works perfectly, of course.

And that code is quite correct. Hibernate actually compares the component against an earlier copy of itself.

Hi Gavin,

I'm actually happy to be wrong! So I have not to make every composite immutable!!! :-)

I've tried to reproduce the problem.
It was due a wrong use of Session.lock() method (not in Hibernate, of course). Am I wrong again ?

In the following code I found out that:

-if line1 is commented (no "Session.lock" call, as I think it'd be) user is alway marked as dirty (i.e.: also when I only change a property of userName)

-if line1 is uncommented user is marked as dirty only if line2 is uncommented (i.e.: only if I modify a property of user object)

Can you help me to understand what happens, please?

Thanks for your help (and for the good Hibernate).


[i] public static void doit(String newvalue) throws HibernateException
{
User user = null;
{
Session session = HibernateUtil.createSession();
Transaction tx = session.beginTransaction();
List query = session.find("select user from User as user");

Iterator itr = query.iterator();

if (itr.hasNext())
{
user = (User) itr.next();
System.out.println("Found user id: " + user.getId());
}
tx.commit();

HibernateUtil.closeSession(session);
}

// long transaction

if (user!=null)
{
Session session = HibernateUtil.createSession();
Transaction tx = session.beginTransaction();

//session.lock(user,LockMode.READ); //*****line1

user.getName().setSurname(newvalue);
//user.setNote(newvalue); //*****line2

session.saveOrUpdate(user);

tx.commit();
HibernateUtil.closeSession(session);
}
}[/i]

When you lock() an object, you tell Hibernate to use the current state of the object as the snapshot, ie that you did NOT change the object while it was detached.

I agree with you.

In fact, I used (following code is from previous message) session.lock(user, LockMode.READ) to reassociate the unmodified object (user) and *then* I changed a property of the composite. The object wasn't modified while it was detached, but after.

Shouldn't the object (user) be marked as dirty?


//-----Code from the previous message-----
//session.lock(user,LockMode.READ); //*****line1

user.getName().setSurname(newvalue);

I have confirmed that there is a bug in the implementation of lock() in 2.1.2. This is now fixed in CVS.

I'll check out the new version from cvs.

Thanks for your support.
Bye

Note that readonly CVS is sometimes a few hrs behind the CVS that i am seeing.