Thread: [OJB-developers] RE: Referantial Integrity under ODMG

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Florian

 > Hi Thomas,
 > >
 > > The first bug is on the to do list for quite a long time (item 32).
 > > The ODMG implementation just does not handle RI correctly right now!
 >
 > So this is really a bug and not something I am doing wrong.
 > As I am digging
 > further into the code I think I've found an explanation for
 > the problem.
 > PersistenceBroker maintains a Hashtable of objects to be
 > inserted, updated
 > in a transaction.

The ojb.odmg.TransactionImpl holds a ObjectEnvelopeTable that maintains a
Hashtable of all Objects locked to a Transaction.

(The PersistenceBroker is not involved in these issues. I guess this was 
a typo?)

 >Because the Hashtable returns the objects
 > in random order
 > there is no guarantee that the objects are inserted/updated
 > in the same
 > order as they are queued into PersistenceBroker. If we
 > inserted/updated the
 > objects in the correct order (i.e. the order that they were
 > put into the
 > queue) the problem could be solved. Then there needs to be
 > just a minor
 > modification so that references are stored in
 > PersistenceBroker before the
 > "root" object and collections afterwards.
 >
 > Does this make sense or is this a completely wrong approach.
 >

You are on the right way!
The Objects in the table are stored without proper ordering with respect 
to referential integrity dependencies.

The solution is simple: We have to compute a depency graph for all 
objects locked to the tx. We can use the ClassDescriptor information to 
compute this graph.
My idea (we already had some discussions regarding this issue) was to 
have a comparator based on this depency graph. The comparator can be 
used to sort the elements of the table before the broker is called to 
store objects.

One important note: for insert we have to store master objects first and 
  detail objects later.
For deleting it's just inverse: first delete detail objects, then master 
objects !

<snip>

 > This at least avoids the exception. I now think that the
 > problem has further
 > consequences as it is in bindSelect(PreparedStatement, Identity). The
 > relevant code looks as follows:
 >
 >     public void bindSelect(PreparedStatement stmt, Identity
 > oid) throws
 > java.sql.SQLException
 >     {
 >         int i = 0;
 >         try
 >         {
 >             for (i = 0; i < oid.getPrimaryKeyValues().length; i++)
 >             {
 >                 stmt.setObject(i + 1, oid.getPrimaryKeyValues()[i]);
 >             }
 > 	[...]
 >
 > The problem is when oid.getPrimaryKeyValues()[i] returns
 > null. In this case
 > the Informix driver needs the JDBC-Type of the value to bind.
 > The call would
 > then be
 > 	stmt.setObject(i+1, oid.getPrimaryKeyValues()[i], Types.XXX)
 >
 > In bindInsert for example the type of the parameter can be
 > resolved, the
 > call looks like:
 > 	stmt.setObject(i+1, val, JdbcAccess.getSqlTypeAll(cld, i));
 >
 > If we had the type in bindSelect, the type could be passed to
 > setObject, but
 > we simply do not have this information here. I think we would
 > be on the safe
 > side if we always set the type of the object explicitly.
 > Sometimes JDBC
 > drivers do not know how to map an object to a SQL type and we
 > could support
 > it there.
 >

The jdbc type info can be obtained from the respective ClassDescriptor by:
JdbcAccess.getSqlTypeAll(cld, i)

The ClassDescriptor cld could be obtained by:
ClassDescriptor cld = broker.getClassDescriptor(oid.getObjectsClass());

 > > Of course this is a hack, but I have no idea how to avoid such
 > > situations in a bulletproof way...
 >
 > I think this could be worth a try, but it either requires in
 > depth knowledge
 > of OJB internals or an architectural change in Identity, so I
 > fear I cannot
 > be of any help there.
 >

Maybe the Referential Integrity problem is easier to start with, as it 
does not require so much in depth OJB know how.

I will provide a fix for the second problem in the next release.
So you can concentrate on RI ;-)

 > > hth,
 > >
 > > Thomas
 > >
 >
 > best regards,
 > Florian
 >
 > PS: Wofur steht eigentlich hth?
 >

AFAIK HTH means: hope that helped!

(oder auf deutsch: hier werden Sie geholfen)

cu,

Thomas

Thread: [OJB-developers] RE: Referantial Integrity under ODMG

objectbridge-developers