Issue Details (XML | Word | Printable)

Key: JDO-382
Type: Test Test
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Michelle Caisse
Reporter: Craig Russell
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
JDO

Add test for selecting and updating an embedded field

Created: 31/May/06 01:50 AM   Updated: 19/Oct/06 05:10 PM
Return to search
Component/s: tck2
Affects Version/s: JDO 2 final
Fix Version/s: JDO 2 maintenance release 1

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works JDO-382.patch 2006-06-20 12:52 AM Michelle Caisse 15 kB
Java Source File Licensed for inclusion in ASF works ProjectedSCODoesNotTrackChanges.java 2006-06-24 01:39 AM Michelle Caisse 6 kB

Resolution Date: 19/Oct/06 05:10 PM


 Description  « Hide
If you select an embedded field and change it, we need to verify that the object has changed.

Currently no test exists for this case.

Select Address from Employee where name.startsWith('Michael')
address.zip = "94040";
tx.commit();
verify that address.zip has been changed in the database.


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Michelle Caisse added a comment - 09/Jun/06 01:02 AM
This test will be added as a method in org.apache.jdo.tck.models.embedded.SecondClassObjectsTrackTheirChanges.

Craig Russell added a comment - 18/Jun/06 11:29 PM
The proposal is:

Projected SCOs are never owned, projected FCOs are always managed. Modifying unowned SCOs never has an effect on the database. Modifying FCOs no matter how you get them always has an effect if the tx commits.


Michelle Caisse added a comment - 20/Jun/06 12:52 AM
See attached patch for this issue. I have added a method to test changing a projected embedded field and another method that tests changing a projected Date field. Only these methods are new, but the entire file is in the diff because I changed tabs to spaces and broke long lines.

JPOX passes the new test for embedded fields but fails on a Date field:

    [java] 1) testDateField(org.apache.jdo.tck.models.embedded.SecondClassObjectsTrackTheirChanges)junit.framework.AssertionFailedError:
    [java] Expected Company instance not to be dirty; actual state is {persistent, transactional, dirty}
    [java] Expected projected field value is Fri Jun 16 04:29:21 PDT 2006; actual value is Wed Dec 31 16:02:03 PST 1969
    [java]
    [java] at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1052)
    [java] at org.apache.jdo.tck.models.embedded.SecondClassObjectsTrackTheirChanges.testDateField(SecondClassObjectsTrackTheirChanges.java:233)
    [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:237)
    [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:107)
    [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:147)
    [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:122)

Michelle Caisse added a comment - 24/Jun/06 01:39 AM
As suggested by Michael Bouschen, I have moved the new test methods to a new file in query.result. The new file is attached.

Craig Russell added a comment - 24/Jun/06 01:45 AM
Looks good. Just one comment.

The javadoc comment on testDateField should not refer to embedded but to mutable SCO or Date field.

Michael Bouschen added a comment - 24/Jun/06 02:09 AM
Looks good. A few comments:

- Please break the long line in the class javadoc comment.
- Would it make sense to make method getPersistentNewInstance private?
- The following comment might be confusing because the modification is not stored in teh database.
  // Select address/date, modify, and persist
- Both test methods testEmbeddedField and testDateField execute the same query twice. There is no need to call pm.newQuery again and specify exactly the same query. You can just call query.execute after staring the third transaction.

Michelle Caisse added a comment - 24/Jun/06 12:05 PM
I made the suggested changes and checked in the new test file. I added the test to conf/query.conf. Revision: 416861

I will leave the issue open until the correct assertion number is available to be entered in the source file comments.

Michelle Caisse added a comment - 19/Oct/06 05:10 PM
Updated assertion number and text with revision: 465685