Hi Gordon,
Please find my new version of the fix for issue 1021
attached. Following is a summary of the changes:
ObjectBuilder: passing the class type to the ObjectChangeSet constructor
AggregateObjectChangeSet: added class type parameter to the constructor
ObjectChangeSet: added class type parameter to the constructor
UnitOfWorkChangeSet: determinating the class type by using the
ConvertionManager, if the tofind clone was loaded with the current
class loader; *Question*: What to do if tofind clone was laoded with
different class loader? - Please see inside class.
SuperLargeProject: added non-entity subclass for testing purpose
EntityManagerJUnitTestSuite: the test associates an SuperLargeProject
to an Employee instance, which is then persisted. Since saving the
Employee also creates a join table entry for the relationship, the
test would fail, if SuperLargeProject wasn't stored as Project.
Thanks again for your previous suggestions and please let me know your
opinion on the question about the UnitOfWorkChangeSet implementation!
-- markus.
Gordon Yorke wrote:
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
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
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.
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