Hello All,

I am new to Hibernate and currently evaulating hibernate 3.1b3 for a project.

I thought that it would be a good starting point to load and run hibernate test suite. I used default parameters under \etc folder and hsqldb1.7.3. with EHCache 1.1.

1. I modified the the class org.hibernate.test.Fum such that it no longer implements Lifecycle.

I run the test and it failed with

13:53:13,287 ERROR AbstractFlushingEventListener:299 - Could not synchronize database state with session
org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: org.hibernate.test.legacy.Fum


Criteria base = s.createCriteria(Fum.class)
.add( Expression.like("fum", "f", MatchMode.START) );
base.createCriteria("fo")
.add( Expression.isNotNull("fum") );
base.createCriteria("friends")
.add( Expression.like("fum", "g%") );

List list = base.list(); <<<< this line is the source of failure


So, does that mean that hibernate actually DOES NOT traverse the object graph to detect the persistable types and try to persist them along with?

2. I modified the code of FumTest.testCriteria() test such that it makes a manual call to Fum.onSave() like
s.save(fr);
s.save(fr2);
s.save( fum.getFo() );
fum.onSave( s ); <<<<< I added this line
s.save(fum);

so that I was expecting the test to pass. But it actually DID NOT. I got the same error message as above.

In fact, I think the added line is not even necessary since Fum:onSave() only persists friends of our fum and the previous three lines above already save his only friends fr and fr2, already.

Obviously, I am missing a point in here? What is the difference between manually persisting all the dependent objects and using Lifecycle?

3. In another test class MasterDetailTest I tried to modify the tests so that they can work with new bulk updates.

here is the original code from MasterDetailTest.testNoUpdateManyToOne()

s = openSession();
s.update(z);
s.flush();
s.delete(z);
s.delete("from W");

I changed the last line as
s.createQuery("delete from W").executeUpdate();

but that failed with the dabase error.

Caused by: java.sql.SQLException: Integrity constraint violation FK5A435CA81F table: Z in statement [delete from W]

Obviously the database did not get hit with the previous line
s.delete(z);

So I added another s.flush() just after the line above then it works fine. But why?
the older implementation did not require that line. Does the batch update comands honour FlushMode settings?

Thank you for your patience in reading and, hopefully, posting a response

Regards,
Kemerd