persistence@glassfish.java.net

Re: [Fwd: [Issue 1021] OneToMany Cascade Persist Failure due to Insert Order]

From: Markus Fuchs <Markus.Fuchs_at_Sun.COM>
Date: Mon, 09 Oct 2006 16:01:44 -0700
Hi Gordon,
     Perhaps a more effecient way of handling this issue is to have the ObjectBuilder set the Class type in the ObjectChangeSet from the Descriptor in the ObjectBuilder.  Then there would be no need to perform a Descriptor lookup later in UnitOfWorkChangeSet.
Good idea! That would either involve

* passing the classType to the constructor, or
* not setting the classType and className in the constructor and setting it from outside.

The two methods creating ObjectChangeSets are

ObjectBuilder.createObjectChangeSet
UnitOfWorkChangeSet.findOrIntegrateObjectChangeSet

Looks like the descriptor is not available in the UnitOfWorkChangeSet.findOrIntegrateObjectChangeSet call...

Another question:

in ObjectBuilder.createObjectChangeSet

            if (getDescriptor().isAggregateDescriptor()) {
                changes = new AggregateObjectChangeSet(new Vector(0), clone, uowChangeSet, isNew);
            } else {
                changes = new ObjectChangeSet(extractPrimaryKeyFromObject(clone, session), clone, uowChangeSet, isNew);
            }
            changes.setIsAggregate(getDescriptor().isAggregateDescriptor() || getDescriptor().isAggregateCollectionDescriptor());

meaning that a "regular" ObjectChangeSet is created, if getDescriptor().isAggregateCollectionDescriptor() is true. Is that intended?

Thanks,

-- markus.
--Gordon
-----Original Message-----
From: Markus.Fuchs@Sun.COM [mailto:Markus.Fuchs@Sun.COM]On Behalf Of Markus Fuchs
Sent: Wednesday, October 04, 2006 2:48 PM
To: Gordon Yorke
Subject: Re: [Fwd: [Issue 1021] OneToMany Cascade Persist Failure due to Insert Order]

Hi Gordon,

did you get a chance to look at this?

Thanks!

-- markus.

Markus Fuchs wrote:
Hi Gordon,

could you please give me your opinion?

Thanks!

-- markus.



Subject:
[Issue 1021] OneToMany Cascade Persist Failure due to Insert Order
From:
mf125085@dev.java.net
Date:
Mon, 02 Oct 2006 19:56:41 +0000
To:
issues@glassfish.dev.java.net
To:
issues@glassfish.dev.java.net

https://glassfish.dev.java.net/issues/show_bug.cgi?id=1021






------- Additional comments from mf125085@dev.java.net Mon Oct  2 19:56:41 +0000 2006 -------
I'm attaching a possible fix for issue 1021. The fix basically
registers and removes new instances for non-entity classes in the
Hashtable of the closest entity super class. During flush, the
instances are written to the database from there.

I think that we have to do this twist only for new instance, since
TopLink will never return non-entity instances for any entity manager
operation or queries.

What do you think?


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: issues-help@glassfish.dev.java.net