[jira] Assigned: (JDO-343) JPOX regression: after deserializing a detached instance, the instance is transient
[ http://issues.apache.org/jira/browse/JDO-343?page=all ]
Andy Jefferson reassigned JDO-343:
--
Assign To: Andy Jefferson (was: Erik Bengtson)
> JPOX regression: after deserializing a detached instance, the instance is
> transient
> ---
>
> Key: JDO-343
> URL: http://issues.apache.org/jira/browse/JDO-343
> Project: JDO
> Type: Bug
> Components: tck20
> Versions: JDO 2 rc1
> Reporter: Craig Russell
> Assignee: Andy Jefferson
> Fix For: JDO 2 final
>
> With the JPOX SNAPSHOT from 20-Mar-2006, the DetachSerialize test now fails.
> [java] Description: Detachment tests with standard mapping, no testdata.
> [java] Time: 010
> [java] There was 1 failure:
> [java] 1)
> testDetachSerialize(org.apache.jdo.tck.api.persistencemanager.detach.DetachSerialize)junit.framework.AssertionFailedError:
>
> [java] Assertion A12.6.8 (DetachSerialize) failed: after deserializing
> cart,
> [java] Cart instance should be detached but is not. The object state is:
> transient {}
> [java] Assertion A12.6.8 (DetachSerialize) failed: after deserializing
> cart,
> [java] CartEntry instance should be detached but is not. The object state
> is: transient {}
> [java] Assertion A12.6.8 (DetachSerialize) failed: after deserializing
> cart,
> [java] Product instance should be detached but is not. The object state
> is: transient {}
> [java]
> [java] at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1035)
> [java] at
> org.apache.jdo.tck.api.persistencemanager.detach.DetachSerialize.testDetachSerialize(DetachSerialize.java:73)
> [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:232)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:105)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:143)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:118)
> [java] FAILURES!!!
--
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] Resolved: (JDO-343) JPOX regression: after deserializing a detached instance, the instance is transient
[ http://issues.apache.org/jira/browse/JDO-343?page=all ]
Andy Jefferson resolved JDO-343:
Resolution: Fixed
Fixed in JPOX CVS ... again. RIP.
> JPOX regression: after deserializing a detached instance, the instance is
> transient
> ---
>
> Key: JDO-343
> URL: http://issues.apache.org/jira/browse/JDO-343
> Project: JDO
> Type: Bug
> Components: tck20
> Versions: JDO 2 rc1
> Reporter: Craig Russell
> Assignee: Andy Jefferson
> Fix For: JDO 2 final
>
> With the JPOX SNAPSHOT from 20-Mar-2006, the DetachSerialize test now fails.
> [java] Description: Detachment tests with standard mapping, no testdata.
> [java] Time: 010
> [java] There was 1 failure:
> [java] 1)
> testDetachSerialize(org.apache.jdo.tck.api.persistencemanager.detach.DetachSerialize)junit.framework.AssertionFailedError:
>
> [java] Assertion A12.6.8 (DetachSerialize) failed: after deserializing
> cart,
> [java] Cart instance should be detached but is not. The object state is:
> transient {}
> [java] Assertion A12.6.8 (DetachSerialize) failed: after deserializing
> cart,
> [java] CartEntry instance should be detached but is not. The object state
> is: transient {}
> [java] Assertion A12.6.8 (DetachSerialize) failed: after deserializing
> cart,
> [java] Product instance should be detached but is not. The object state
> is: transient {}
> [java]
> [java] at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1035)
> [java] at
> org.apache.jdo.tck.api.persistencemanager.detach.DetachSerialize.testDetachSerialize(DetachSerialize.java:73)
> [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:232)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:105)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:143)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:118)
> [java] FAILURES!!!
--
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-345) MethodsAndObjectConstructionNotSupported (A14.6.2-8) should allow getX()
[ http://issues.apache.org/jira/browse/JDO-345?page=comments#action_12371473 ] Michael Bouschen commented on JDO-345: -- I agree we should drop the test from the TCK. It might make sense to have a negative test case with a query calling a mutating method such as Collection.add. Calling a mutating method is not allowed in JDOQL. > MethodsAndObjectConstructionNotSupported (A14.6.2-8) should allow getX() > > > Key: JDO-345 > URL: http://issues.apache.org/jira/browse/JDO-345 > Project: JDO > Type: Test > Components: tck20 > Reporter: Ilan Kirsh > > According to the spec: > "Methods, including object construction, are not supported, except for > Collection, String, and Map methods documented below. Implementations might > choose to support non-mutating method calls as non-standard extensions." > However, MethodsAndObjectConstructionNotSupported expects an exception for > method getX(). -- 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-345) MethodsAndObjectConstructionNotSupported (A14.6.2-8) should allow getX()
[ http://issues.apache.org/jira/browse/JDO-345?page=comments#action_12371478 ] Ilan Kirsh commented on JDO-345: I also think that this test should be dropped. A negative test might cause a new problem - how the implementation can check if a method is mutating in the general case? I think we already have enough byte code processing in the enhancer. > MethodsAndObjectConstructionNotSupported (A14.6.2-8) should allow getX() > > > Key: JDO-345 > URL: http://issues.apache.org/jira/browse/JDO-345 > Project: JDO > Type: Test > Components: tck20 > Reporter: Ilan Kirsh > > According to the spec: > "Methods, including object construction, are not supported, except for > Collection, String, and Map methods documented below. Implementations might > choose to support non-mutating method calls as non-standard extensions." > However, MethodsAndObjectConstructionNotSupported expects an exception for > method getX(). -- 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-345) MethodsAndObjectConstructionNotSupported (A14.6.2-8) should allow getX()
[ http://issues.apache.org/jira/browse/JDO-345?page=comments#action_12371488 ] Craig Russell commented on JDO-345: --- I think a word about why we used the term "mutating method" is in order here. The expert group did not want to allow the user and implementation to use query as a back door to a generalized UPDATE facility, so we said specifically that mutating methods were not allowed, even in vendor extensions. That said, there are only a small number of standard mutating methods that return a value, and hence even could be used in a filter. So I think we are safe in dropping this test and we can debate the value of a new test later on if someone wants to raise the issue again. > MethodsAndObjectConstructionNotSupported (A14.6.2-8) should allow getX() > > > Key: JDO-345 > URL: http://issues.apache.org/jira/browse/JDO-345 > Project: JDO > Type: Test > Components: tck20 > Reporter: Ilan Kirsh > > According to the spec: > "Methods, including object construction, are not supported, except for > Collection, String, and Map methods documented below. Implementations might > choose to support non-mutating method calls as non-standard extensions." > However, MethodsAndObjectConstructionNotSupported expects an exception for > method getX(). -- 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: serialize Detachable instance for storage
Hi Erik, On Mar 17, 2006, at 11:40 AM, Erik Bengtson wrote: Hi, If we serialize a detachable instance for storage, does it have the detach state populated? Yes. Regardless of whether it's currently managed or already detached, the detached state is part of the serialized state of the instance. It is at least a waste of space. I don't understand how the detached state is wasted space. It contains information that's needed if the instance is in future attached to a persistence manager. Craig Regards Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[jira] Resolved: (JDO-258) Write tests for new persistent-nontransactional-dirty lifecycle assertions
[ http://issues.apache.org/jira/browse/JDO-258?page=all ] Martin Zaun resolved JDO-258: - Resolution: Fixed Combined patch for JDO-275 and JDO-258 committed with revision 388087. > Write tests for new persistent-nontransactional-dirty lifecycle assertions > -- > > Key: JDO-258 > URL: http://issues.apache.org/jira/browse/JDO-258 > Project: JDO > Type: Test > Components: tck20 > Versions: JDO 2 beta > Reporter: Michelle Caisse > Assignee: Craig Russell > Fix For: JDO 2 final > > A5.6.2-3 [A persistent-nontransactional-dirty instance transitions to hollow > if it is the parameter of evict or evictAll. This allows the application to > remove instances from the set of instances whose state is to be committed to > the datastore.] > A5.6.2-5 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow. ] > A5.6.2-7 [The persistent-nontransactional-dirty instances will transition > according to the RestoreValues flag. With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] > A5.6.2-9 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow.] > A5.6.2-11 [With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] -- 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-258) Write tests for new persistent-nontransactional-dirty lifecycle assertions
[ http://issues.apache.org/jira/browse/JDO-258?page=all ] Martin Zaun updated JDO-258: Comment: was deleted > Write tests for new persistent-nontransactional-dirty lifecycle assertions > -- > > Key: JDO-258 > URL: http://issues.apache.org/jira/browse/JDO-258 > Project: JDO > Type: Test > Components: tck20 > Versions: JDO 2 beta > Reporter: Michelle Caisse > Assignee: Craig Russell > Fix For: JDO 2 final > > A5.6.2-3 [A persistent-nontransactional-dirty instance transitions to hollow > if it is the parameter of evict or evictAll. This allows the application to > remove instances from the set of instances whose state is to be committed to > the datastore.] > A5.6.2-5 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow. ] > A5.6.2-7 [The persistent-nontransactional-dirty instances will transition > according to the RestoreValues flag. With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] > A5.6.2-9 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow.] > A5.6.2-11 [With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] -- 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-258) Write tests for new persistent-nontransactional-dirty lifecycle assertions
[ http://issues.apache.org/jira/browse/JDO-258?page=comments#action_12371519 ] Martin Zaun commented on JDO-258: - Combined patch for JDO-275 and JDO-258 committed with revision 388087. > Write tests for new persistent-nontransactional-dirty lifecycle assertions > -- > > Key: JDO-258 > URL: http://issues.apache.org/jira/browse/JDO-258 > Project: JDO > Type: Test > Components: tck20 > Versions: JDO 2 beta > Reporter: Michelle Caisse > Assignee: Craig Russell > Fix For: JDO 2 final > > A5.6.2-3 [A persistent-nontransactional-dirty instance transitions to hollow > if it is the parameter of evict or evictAll. This allows the application to > remove instances from the set of instances whose state is to be committed to > the datastore.] > A5.6.2-5 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow. ] > A5.6.2-7 [The persistent-nontransactional-dirty instances will transition > according to the RestoreValues flag. With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] > A5.6.2-9 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow.] > A5.6.2-11 [With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] -- 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-258) Write tests for new persistent-nontransactional-dirty lifecycle assertions
[ http://issues.apache.org/jira/browse/JDO-258?page=all ] Martin Zaun updated JDO-258: Comment: was deleted > Write tests for new persistent-nontransactional-dirty lifecycle assertions > -- > > Key: JDO-258 > URL: http://issues.apache.org/jira/browse/JDO-258 > Project: JDO > Type: Test > Components: tck20 > Versions: JDO 2 beta > Reporter: Michelle Caisse > Assignee: Craig Russell > Fix For: JDO 2 final > > A5.6.2-3 [A persistent-nontransactional-dirty instance transitions to hollow > if it is the parameter of evict or evictAll. This allows the application to > remove instances from the set of instances whose state is to be committed to > the datastore.] > A5.6.2-5 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow. ] > A5.6.2-7 [The persistent-nontransactional-dirty instances will transition > according to the RestoreValues flag. With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] > A5.6.2-9 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow.] > A5.6.2-11 [With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] -- 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-258) Write tests for new persistent-nontransactional-dirty lifecycle assertions
[ http://issues.apache.org/jira/browse/JDO-258?page=comments#action_12371520 ] Martin Zaun commented on JDO-258: - Combined patch for JDO-273 and JDO-258 committed with revision 388087. > Write tests for new persistent-nontransactional-dirty lifecycle assertions > -- > > Key: JDO-258 > URL: http://issues.apache.org/jira/browse/JDO-258 > Project: JDO > Type: Test > Components: tck20 > Versions: JDO 2 beta > Reporter: Michelle Caisse > Assignee: Craig Russell > Fix For: JDO 2 final > > A5.6.2-3 [A persistent-nontransactional-dirty instance transitions to hollow > if it is the parameter of evict or evictAll. This allows the application to > remove instances from the set of instances whose state is to be committed to > the datastore.] > A5.6.2-5 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow. ] > A5.6.2-7 [The persistent-nontransactional-dirty instances will transition > according to the RestoreValues flag. With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] > A5.6.2-9 [The persistent-nontransactional-dirty instances will transition > according to the RetainValues flag. With the RetainValues flag set to true, > persistent-nontransactional-dirty instances will transition to > persistent-nontransactional. With the RetainValues flag set to false, > persistent-nontransactional-dirty instances will transition to hollow.] > A5.6.2-11 [With the RestoreValues flag set to true, > persistent-nontransactional-dirty instances will make no state transition, > but the fields will be restored to their values as of the beginning of the > transaction, and any changes made within the transaction will be discarded. > With the RestoreValues flag set to false, persistent-nontransactional-dirty > instances will transition to hollow.] -- 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
