Hi,

AFAIK has the order of operations not changed (the last ten releases).
If you store an object with 1:1 and 1:n references (and auto-update is
true/object) OJB do:

- first store the 1:1 references, because we need the PK values as FK in
main object
- set the 1:1 reference FK value and store the main object
- set the FK values in the 1:n references (the PK values of the main object)
- store the 1:n references

How should we change this order?

would it break anything if we stored the 1:1 references last, or just
before the 1:n references?

yep, see above.


I know making this move would solve my odd PK problem, but would it
>>break
things for others?

If you don't use auto-update true/object/link and set the FK values by your own (or use the OJB-link methods) it is possible to change the order.

regards,
Armin


Edson Carlos Ericksson Richter wrote:

I'm having this problem too... When (or in what version) this order of
operations has changed?

Thanks,

Richter


Em Qui, 2004-08-26 �s 15:38, Brian Latimer escreveu:

I've noted that when storing an object, the first step done is to store the 1 to 1 references, then the object itself is stored and then finally, the 1 to n or m to n references are stored.


Is there a reason for this order of operations?

would it break anything if we stored the 1:1 references last, or just before the 1:n references?

I know making this move would solve my odd PK problem, but would it break things for others?


Code follows: ****************************************************************************************************************

private void storeToDb(Object obj, ClassDescriptor cld, Identity oid, boolean insert)
{
// 1. link and store 1:1 references
storeReferences(obj, cld, insert);


Object[] pkValues = oid.getPrimaryKeyValues();
if (!serviceBrokerHelper().assertValidPkFields(cld.getPkFields(), pkValues))
{
// BRJ: fk values may be part of pk, but the are not known during
// creation of Identity. so we have to get them here
pkValues = serviceBrokerHelper().getKeyValues(cld, obj);
if (!serviceBrokerHelper().assertValidPkFields(cld.getPkFields(), pkValues))
{
String append = insert ? " on insert" : " on update" ;
throw new PersistenceBrokerException("assertValidPkFields failed for Object of type: " + cld.getClassNameOfObject() + append);
}
}


// setreferenceFKs for auto_inc dbs - this can be ignored by hi low or any that do pre assignment
try
{
sequenceManager.setReferenceFKs(obj, cld);
}
catch (SequenceManagerException e)
{
logger.error("Setting of reference FK failed", e);
throw new PersistenceBrokerException(e);
}
// get super class cld then store it with the object
/*
now for multiple table inheritance
1. store super classes, topmost parent first
2. go down through heirarchy until current class
3. todo: store to full extent?


This if-clause will go up the inheritance heirarchy to store all the super classes.
The id for the top most super class will be the id for all the subclasses too
*/
if(cld.getSuperClass() != null)
{


ClassDescriptor superCld = getDescriptorRepository().getDescriptorFor(cld.getSuperClass());
storeToDb(obj, superCld, oid, insert);
// arminw: why this?? I comment out this section
// storeCollections(obj, cld.getCollectionDescriptors(), insert);
}


// 2. store primitive typed attributes (Or is THIS step 3 ?)
// if obj not present in db use INSERT
if (insert)
{
dbAccess.executeInsert(cld, obj);
// Let SequenceManager update id if necessary, should only happen after an insert
try
{
sequenceManager.afterStore(dbAccess, cld, obj);
}
catch (SequenceManagerException e)
{
logger.error("SQLException during SequenceManager.afterStore call on object '"
+ cld.getClassOfObject().getName() + "': " + e.getMessage(), e);
throw new PersistenceBrokerException(e);
}
}
// else use UPDATE
else
{
dbAccess.executeUpdate(cld, obj);
}
// Create a new Identity based on the current set of primary key values.
Identity newOid = new Identity(obj, this, cld);
// cache object for symmetry with getObjectByXXX()
// Add the object to the cache.
objectCache.cache(newOid, obj);
// 3. store 1:n and m:n associations
storeCollections(obj, cld, insert);
}




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to