Re: Autoincriment FK and PK problem

[Brian Latimer]

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]