[jira] Assigned: (JDO-144) Incorrect value for public Collection CollectionOfDate12
[ http://issues.apache.org/jira/browse/JDO-144?page=all ] Andy Jefferson reassigned JDO-144: -- Assign To: Andy Jefferson (was: Michelle Caisse) The reason you get a "org.jpox.sco.Collection" when inspecting the type of the collection field *whilst within the transaction* is that a JDO implementation has to be able to detect changes to the Collection field (addition of elements, removal of elements, etc). If you'd done it outside the transaction then it would have been java.util.Vector. The TCK cannot justifiably test for the type of the collection field (since it may be a JDO impl wrapper type) but it can justifiably test for whether it is "instanceof" the expected type. The error in that particular part is that JPOX is assigning a wrapper type of the declared type and not of the instantiated type, and consequently the cast fails. > Incorrect value for public Collection CollectionOfDate12 > > > Key: JDO-144 > URL: http://issues.apache.org/jira/browse/JDO-144 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michelle Caisse > Assignee: Andy Jefferson > > [java] 1) > test(org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections)junit.framework.AssertionFailedError: > Assertion A6.4.3-33 (TestCollectionCollections) failed: > [java] Incorrect value for public Collection CollectionOfDate12 > [java] at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) > [java] at > org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.checkValues(TestCollectionCollections.java:146) > [java] at > org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:104) > [java] at > org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [java] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:115) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:93) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JDO-168) XML query testdata needs to be extended for new JDO 2 query tests
XML query testdata needs to be extended for new JDO 2 query tests - Key: JDO-168 URL: http://issues.apache.org/jira/browse/JDO-168 Project: JDO Type: Improvement Components: tck20 Reporter: Michael Watzek Assigned to: Michael Watzek The new JDO 2 query test cases require more complex testdata than contained in 'companyForQueryTests.xml'. I propose to copy the content of 'companyAllRelationships.xml' into 'companyForQueryTests.xml'. Due to this change some existing query tests must be adapted wrt the expected query result: - test\java\org\apache\jdo\tck\query\jdoql\methods\SupportedCollectionMethods.java - test\java\org\apache\jdo\tck\query\jdoql\NavigationThroughReferencesUsesDotOperator.java - test\java\org\apache\jdo\tck\query\jdoql\Cast.java - test\java\org\apache\jdo\tck\query\jdoql\DenoteUniquenessInFilter.java - test\java\org\apache\jdo\tck\query\jdoql\NullCollectionsAndContainsMethod.java - test\java\org\apache\jdo\tck\query\jdoql\operators\EqualityAndComparisonsBetweenDateFieldsAndParameters.java - test\java\org\apache\jdo\tck\query\jdoql\operators\EqualityAndComparisonsBetweenStringFieldsAndParameters.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JDO-168) XML query testdata needs to be extended for new JDO 2 query tests
[ http://issues.apache.org/jira/browse/JDO-168?page=all ] Michael Watzek updated JDO-168: --- Attachment: JDO-168.patch The patch fixes the issues above. Applying this patch, JPOX returns two more failures with alltests.conf for both, application identity and datastore identity. The test cases NavigationThroughANullValuedField and NavigationThroughReferencesUsesDotOperator fail due to unexpected query results. JPOX generates an incomplete SQL statement for the query missing a discriminator comparison for a relationship navigation. For this reason, the query returns more results than expected. I'll file a separate issue. > XML query testdata needs to be extended for new JDO 2 query tests > - > > Key: JDO-168 > URL: http://issues.apache.org/jira/browse/JDO-168 > Project: JDO > Type: Improvement > Components: tck20 > Reporter: Michael Watzek > Assignee: Michael Watzek > Attachments: JDO-168.patch > > The new JDO 2 query test cases require more complex testdata than contained > in 'companyForQueryTests.xml'. I propose to copy the content of > 'companyAllRelationships.xml' into 'companyForQueryTests.xml'. > Due to this change some existing query tests must be adapted wrt the expected > query result: > - > test\java\org\apache\jdo\tck\query\jdoql\methods\SupportedCollectionMethods.java > - > test\java\org\apache\jdo\tck\query\jdoql\NavigationThroughReferencesUsesDotOperator.java > - test\java\org\apache\jdo\tck\query\jdoql\Cast.java > - test\java\org\apache\jdo\tck\query\jdoql\DenoteUniquenessInFilter.java > - > test\java\org\apache\jdo\tck\query\jdoql\NullCollectionsAndContainsMethod.java > - > test\java\org\apache\jdo\tck\query\jdoql\operators\EqualityAndComparisonsBetweenDateFieldsAndParameters.java > - > test\java\org\apache\jdo\tck\query\jdoql\operators\EqualityAndComparisonsBetweenStringFieldsAndParameters.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JDO-169) JPOX generates wrong SQL statements navigating relationships in JDO queries
JPOX generates wrong SQL statements navigating relationships in JDO queries --- Key: JDO-169 URL: http://issues.apache.org/jira/browse/JDO-169 Project: JDO Type: Improvement Components: tck20 Reporter: Michael Watzek Assigned to: Erik Bengtson This bug shows up in (at least) two test cases: NavigationThroughANullValuedField and NavigationThroughReferencesUsesDotOperator. Both test cases run the following JDO query: SELECT FROM Employee WHERE medicalInsurance.carrier == \"Carrier1\". JPOX generates the following SQL: SELECT THIS.DISCRIMINATOR,THIS.BIRTHDATE,THIS.FIRSTNAME,THIS.LASTNAME,THIS.PERSONID,THIS.HIREDATE,THIS.WEEKLYHOURS FROM applicationidentity0.PERSONS THIS LEFT OUTER JOIN applicationidentity0.INSURANCEPLANS RELATED14 ON RELATED14.EMPLOYEE = THIS.PERSONID WHERE (THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.Employee' OR THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.PartTimeEmployee' OR THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.FullTimeEmployee') AND RELATED14.CARRIER = 'Carrier1' The WHERE clause of this SQL statement misses a discriminator comparison for the navigated relationship: AND RELATED14.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.MedicalInsurance' Once, the patch of JDO-168 has been checked in the test cases mentioned above fail due to this reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JDO-168) XML query testdata needs to be extended for new JDO 2 query tests
[ http://issues.apache.org/jira/browse/JDO-168?page=comments#action_12331384 ] Michael Watzek commented on JDO-168: I filed JDO-169 describing the bug and the solution. > XML query testdata needs to be extended for new JDO 2 query tests > - > > Key: JDO-168 > URL: http://issues.apache.org/jira/browse/JDO-168 > Project: JDO > Type: Improvement > Components: tck20 > Reporter: Michael Watzek > Assignee: Michael Watzek > Attachments: JDO-168.patch > > The new JDO 2 query test cases require more complex testdata than contained > in 'companyForQueryTests.xml'. I propose to copy the content of > 'companyAllRelationships.xml' into 'companyForQueryTests.xml'. > Due to this change some existing query tests must be adapted wrt the expected > query result: > - > test\java\org\apache\jdo\tck\query\jdoql\methods\SupportedCollectionMethods.java > - > test\java\org\apache\jdo\tck\query\jdoql\NavigationThroughReferencesUsesDotOperator.java > - test\java\org\apache\jdo\tck\query\jdoql\Cast.java > - test\java\org\apache\jdo\tck\query\jdoql\DenoteUniquenessInFilter.java > - > test\java\org\apache\jdo\tck\query\jdoql\NullCollectionsAndContainsMethod.java > - > test\java\org\apache\jdo\tck\query\jdoql\operators\EqualityAndComparisonsBetweenDateFieldsAndParameters.java > - > test\java\org\apache\jdo\tck\query\jdoql\operators\EqualityAndComparisonsBetweenStringFieldsAndParameters.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JDO-169) JPOX generates wrong SQL statements navigating relationships in JDO queries
[ http://issues.apache.org/jira/browse/JDO-169?page=all ] Michael Watzek updated JDO-169: --- type: Bug (was: Improvement) > JPOX generates wrong SQL statements navigating relationships in JDO queries > --- > > Key: JDO-169 > URL: http://issues.apache.org/jira/browse/JDO-169 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Erik Bengtson > > This bug shows up in (at least) two test cases: > NavigationThroughANullValuedField and > NavigationThroughReferencesUsesDotOperator. > Both test cases run the following JDO query: SELECT FROM Employee WHERE > medicalInsurance.carrier == \"Carrier1\". > JPOX generates the following SQL: > SELECT > THIS.DISCRIMINATOR,THIS.BIRTHDATE,THIS.FIRSTNAME,THIS.LASTNAME,THIS.PERSONID,THIS.HIREDATE,THIS.WEEKLYHOURS > FROM applicationidentity0.PERSONS THIS LEFT OUTER JOIN > applicationidentity0.INSURANCEPLANS RELATED14 ON RELATED14.EMPLOYEE = > THIS.PERSONID WHERE (THIS.DISCRIMINATOR = > 'org.apache.jdo.tck.pc.company.Employee' OR THIS.DISCRIMINATOR = > 'org.apache.jdo.tck.pc.company.PartTimeEmployee' OR THIS.DISCRIMINATOR = > 'org.apache.jdo.tck.pc.company.FullTimeEmployee') AND RELATED14.CARRIER = > 'Carrier1' > The WHERE clause of this SQL statement misses a discriminator comparison for > the navigated relationship: > AND RELATED14.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.MedicalInsurance' > Once, the patch of JDO-168 has been checked in the test cases mentioned above > fail due to this reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Inheritance test schema 2
Hi Andy, in last t-conference, we decided to file a JIRA (http://issues.apache.org/jira/browse/JDO-167) on this issue. Craig proposed to drop the identity types on the PK columns of tables persons, fulltimeemployees, and parttimeemployees. Instead, an implementation-defined sequence should be used to generate unique PK values for the three tables. My understanding is that we do not introduce FKs from parttimeemployees to persons and from fulltimeemployees to persons. Also, we do not introduce inheritance elements in the ORM for FullTimeEmployee and PartTimeEmployee. Does JPOX support such a mapping? Regards, Michael Hi Andy, I agree that inheritance mapping 2 is missing some orm information wrt Employee relationships. Due to this lack, implementations cannot figure out the right runtime type at navigation time, e.g. navigating from Project to Employee. For this reason we need to adapt the orm and the schema. Let's discuss this in tomorrow's t-conference. There are some options: 1) We drop identity column types from tables fulltimeemployees and parttimeemployees. We add fks between tables fulltimeemployees/persons and parttimeemployees/persons. We add orm inheritance joins between classes FullTimeEmployee/Person and PartTimeEmployee/Person. Question: Having these changes, does it still make sense to duplicate persons columns in tables fulltimeemployees and parttimeemployees? 2) We add orm relationship joins to all fields of type Employee. These join elements would contain information about the dynamic runtime type of the relationship. Question: Is the orm dtd descriptive enough to assign this information to join elements? 3) More options? Regards, Michael I've not gone through the data created by the test, only the first few records and the fact that it is creating these duplicate records (as I call them). Here's an issue for you Michael. This is the real issue behind our discussion earlier. Hopefully this simplifies it all :-) In the schema for "inheritance2" we have the Person class with its own table CREATE TABLE persons ( DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY, ... ) and then we have the subclasses with these tables CREATE TABLE fulltimeemployees ( DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY, ... ) CREATE TABLE parttimeemployees ( DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY, ... ) So when a JDO impl wants to insert a FullTimeEmployee object it will try to insert a row into PERSONS, and the fact that you have IDENTITY on the column will allocate an id. It will then try to insert into FULLTIMEEMPLOYEES, and will try to allocate a (possibly different) identity since you have IDENTITY on that table too! Only the root table should have IDENTITY specified - in this case PERSONS. The sub-tables should just be "DATASTORE_IDENTITY INTEGER NOT NULL". This is correct in the schema for "inheritance3" and "inheritance4", but "inheritance2" needs a fix. Returning to the issue of earlier, I had simply seen the above "IDENTITY" specified on these two tables and raised the issue based on that (without looking down to find any base table). The above change will mean that the issue discussed before is likely _not_ going to affect us here since the ids are actually assigned in the root table (PERSONS), and not in PARTTIMEEMPLOYEE/FULLTIMEEMPLOYEE tables, and so you won't get clashes of identity values between FullTime and PartTime employees - the id for a PartTimeEmployee is assigned in the PERSONS table, and the id for a FullTimeEmployee is assigned in the PERSONS table also. Hope that clears it up! -- --- Michael Watzek [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ ---
JDO-168
Hi, I attached a patch to JDO-168 (http://issues.apache.org/jira/browse/JDO-168). Please review. Regards, Michael -- --- Michael Watzek [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ ---
[jira] Assigned: (JDO-144) Incorrect value for public Collection CollectionOfDate12
[ http://issues.apache.org/jira/browse/JDO-144?page=all ] Andy Jefferson reassigned JDO-144: -- Assign To: Michelle Caisse (was: Andy Jefferson) JPOX CVS now has the necessary changes so that the wrapper type used is based on the instantiated type rather than the declared type. As a result, any JPOX builds dated 06/10/2005 onwards will allow you to cast the type of the collection field to be a Vector and then you ought to be able to use List methods. This last part is not tested, but should at least allow further progress on the BigDecimal issue. > Incorrect value for public Collection CollectionOfDate12 > > > Key: JDO-144 > URL: http://issues.apache.org/jira/browse/JDO-144 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michelle Caisse > Assignee: Michelle Caisse > > [java] 1) > test(org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections)junit.framework.AssertionFailedError: > Assertion A6.4.3-33 (TestCollectionCollections) failed: > [java] Incorrect value for public Collection CollectionOfDate12 > [java] at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) > [java] at > org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.checkValues(TestCollectionCollections.java:146) > [java] at > org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:104) > [java] at > org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [java] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:115) > [java] at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:93) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RETRY: Transient instance referencing a detached instance? (was: Question about attachCopy, transient & detached instances)
Hi Matthew,
I'm still trying to ponder the ramifications here, but I think I agree
with your conclusions.
Would it be cleaner to not allow transient instances to be included in
attachCopy() graphs at all? Sounds that way to me.
Wes
Matthew T. Adams wrote:
I'm going to retry sending this email as, after reading the long version,
it's not immediately obvious what I'm asking unless you really read
carefully. So:
SHORT VERSION:
If t is a transient instance of a persistence capable that references a
detached object, then what should happen if the user calls
pm.makePersistent(t)?
I ask because if d is a detached instance that references a transient
instance and I call pm.attachCopy(d), any transient persistence capables
found will have a copy of them made persistent implicitly. This makes me
think that the user (me, that is) would expect symmetry when calling
pm.makePersistent(t), such that any detached objects that t references
should be attached and t's references to those detached objects should be
replaced by their corresponding attached copies.
What do you think?
Also consider the case where the user calls pm.attachCopy(t). I think it
should throw JDOUserException. You?
LONG VERSION:
For all examples in this message, consider "public class A { B b; }" and
"public class B {}", both detachable.
Section 12.6.8, subsection "Attaching instances" says:
Transient instances associated with the detached instances are
copied and the copies are added to the persistent instances in the
corresponding place.
Given this, if I have a detached instance da of type A and a transient
instance tb of type B such that da.b == tb, then the graph after executing
"A pa = (A) pm.attachCopy(da);" should be pa.b == cb, where pa is the
persistent copy of ta and cb is a copy of tb that has been made persistent.
Further,
Transient instances in the parameter list are treated the same as transient
instances reachable from
parameter instances. That is, a copy of each such instance is made
persistent.
Given this, I have a transient instance ta of type A and ta.b == null, then
the graph after executing "A pa = (A) pm.attachCopy(ta);" is pa.b == null,
where pa is the persistent copy of ta.
What should happen if a transient instance is the parameter of the
attachCopy call, and that transient instance holds a reference to a detached
object? I expect a copy of the given transient instance to be made
persistent, and the copy's field that was referencing to the detached object
to point to the detached object's attached copy. For example, if I have a
transient instance ta of type A, a detached instance db of type B such that
a.b == db, then the graph after executing "A pa = (A) pm.attachCopy(ta);"
should be pa.b == cb, where pa is the persistent copy of ta, and cb is the
attached, persistent copy of db.
Is this last example correct? It seems that it should, but the spec also
says:
While detached, an instance might erroneously be assigned as the value of a
persistent field of a persistent
instance or a transient instance that will become persistent either
explicitly or by reachability.
This will result in a JDOUserException being thrown at latest when the
reachability algorithm is run
during flush or commit. The jdo implementation might throw the exception
immediately.
This is actually the case in my last example, where I had a transient
instance of A that referenced a detached instance of B. If I have a
transient instance ta of type A and a detached instance db of type B such
that ta.b == db, will executing "pm.attachCopy(ta)" succeed, while
"pm.makePersistent(ta)" will throw JDOUserException? This seems
inconsistent, since the spec states that "a copy of each such [transient]
instance is made persistent", which, to me, implies that the implementation
will call "pm.makePersistent(ta)" on behalf of the user if he executes
"pm.attachCopy(ta)".
What are the differences between pm.makePersistent and pm.attachCopy when it
comes to transient and detached instances referencing each other?
--matthew
Matthew T. Adams
Corporate Technical Advisor & Senior Consultant
Mobile: +1 253 732 1051
Phone: +1 206 331 3833
Fax: +1 815 331 0952
[EMAIL PROTECTED]
P.O. Box 24163
Federal Way, WA 98093
www.xcalia.com
Xcalia makes implementing SOA easy with agile business intermediation
software that combines heterogeneous data with services to easily develop
and deploy transactional composite applications. Enterprises can quickly
respond to changing business requirements and dramatically reduce the costs
of data access and service integration.
Re: RETRY: Transient instance referencing a detached instance? (was: Question about attachCopy, transient & detached instances)
"Wes Biggs" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Would it be cleaner to not allow transient instances to be included in > attachCopy() graphs at all? Sounds that way to me. > No, I'd like to continue to allow transient instances to be included in attachCopy graphs. I'd like to **add** the ability for detached objects to be included in makePersistent graphs. This use case fell out very naturally for me while working on a website that uses detached objects. I ended up with a transient User object referencing a detached Country object, and, of course, when I called pm.makePersistent(user), I got an JDOUserException as I should have, per the spec as it stands right now. --matthew
Re: RETRY: Transient instance referencing a detached instance?
> > Would it be cleaner to not allow transient instances to be included in > > attachCopy() graphs at all? Sounds that way to me. > > No, I'd like to continue to allow transient instances to be included in > attachCopy graphs. I'd like to **add** the ability for detached objects to > be included in makePersistent graphs. I'll second this requirement. I asked for it on 16 Sep - see the posting in the EG archives titled "makePersistent with a detached object reachable". We need a consistent interface for persistence, and having one method (makePersistent) doing things one way and another(attachCopy) doing it another doesn't help IMHO. A user wants to persist a new object. They want to relate it to another object (in this case detached, but it could be any old object), and then do the persist. Having to work out which method to call in what circumstances, dependent on what objects you just happen to have in the graph is not user-friendly. -- Andy
RE: RETRY: Transient instance referencing a detached instance?
Excellent. Unless there's some technical reason that a user advocate like me can't see, let's make this change. Craig, others, can you please comment? --matthew >-Original Message- >From: Andy Jefferson [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 05, 2005 12:09 PM >To: 'JDO Expert Group'; jdo-dev@db.apache.org >Subject: Re: RETRY: Transient instance referencing a detached instance? > > >> > Would it be cleaner to not allow transient instances to be >included in >> > attachCopy() graphs at all? Sounds that way to me. >> >> No, I'd like to continue to allow transient instances to be >included in >> attachCopy graphs. I'd like to **add** the ability for >detached objects to >> be included in makePersistent graphs. > >I'll second this requirement. >I asked for it on 16 Sep - see the posting in the EG archives titled >"makePersistent with a detached object reachable". >We need a consistent interface for persistence, and having one method >(makePersistent) doing things one way and another(attachCopy) doing it >another doesn't help IMHO. > >A user wants to persist a new object. They want to relate it >to another object >(in this case detached, but it could be any old object), and >then do the >persist. Having to work out which method to call in what >circumstances, >dependent on what objects you just happen to have in the graph is not >user-friendly. > > >-- >Andy >
