Hello Markus,
First answer to your second question, Aggregate Collection objects use the regular ChangeSet they do not need the special AggregateChangeSet.
Second, Passing the class type from the descriptor would be best for the ObjectBuilder. For the UnitOfWorkChangeSet.findOrIntegrateObjectChangeSet, You can use the className from the "toFind" ObjectChangeSet, which you can assume is correct.
--Gordon
-----Original Message-----
From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of Markus Fuchs
Sent: Monday, October 09, 2006 7:02 PM
To: Gordon Yorke; persistence_at_glassfish.dev.java.net
Subject: Re: [Fwd: [Issue 1021] OneToMany Cascade Persist Failure due to Insert Order]
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_at_Sun.COM [mailto:Markus.Fuchs_at_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_at_dev.java.net
Date: Mon, 02 Oct 2006 19:56:41 +0000
To: issues_at_glassfish.dev.java.net
To: issues_at_glassfish.dev.java.net
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1021
------- Additional comments from mf125085_at_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_at_glassfish.dev.java.net
For additional commands, e-mail: issues-help_at_glassfish.dev.java.net