|
Some more comments ...
1. Test does a Query to get the Date of a Company object 2. Test then sets the Date field of the Company object to something else 3. Test then checks if the Company object is dirty. It fails if the Company is dirty ... but of course its dirty since its just had its date changed! 4. Test then does the Query again and compares the Date it got the first time with what it had this time, and fails if they are different. Well it changed the date of the Company in the meantime so of course they are different! I personally would remove the "company.setFounded(testDate)" and instead update the "expectedDate" to a new value. That assumes, of course, that I understand the test correctly :-) The test checks whether a SCO field is transient. SCO wrapper instances should not be returned, but instead the java.util.Date.
SCO wrappers are not returned ... its a java.util.Date that is returned :-P
Andy is right. The test doesn't actually test what it's supposed to. Instead of
comp.setFounded(testDate); it should be something like testDate.setTime(123789L); And then the tests should make sure that the company instance in memory is not dirty (test is ok here) and that the instance in the database still has the same Date as it did earlier, using an equals test. There is a pretty good summary of the issue at http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200606.mbox/%3cB60FB51F-43A4-43AD-A647-75283D6A969E@SUN.com%3e The consensus is that if you project a Date from a query, the Date you get is not an owned SCO. It can be an SCO if your implementation chooses (the only requirement is that it is assignable to Date) but it cannot be owned. The test method projects a Date, modifies it, and then verifies both that the instance in memory whence the projected Date was obtained is not modified, and that the instance in the database is not modified.
Craig Russell made changes - 31/Mar/07 07:01 PM
Fixed with revision: 526916
Michelle Caisse made changes - 09/Apr/07 08:59 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
JPOX fails new test: change to projected Date field is reflected in the database
The comments say "This tests that when a Date field is selected and modified, there is no change in the owned instance.". I interpret this as saying that if I do a query and get a Date field back then if I change that Date, the object in the datastore that it relates to doesnt pick up that change. i.e the Date returned by the Query is not attached to anything.
OK, but the test actually gets a Date in that way and then sets the Date field of a Company object to be this returned Date and checks if the Company object is now dirty. JPOX has actually marked the Company as dirty (even though the date has the same value - which is a minor bug since we should avoid any unnessary datastore update, and I'll fix that), but it is not consistent with the comments of the test.
Should the test not be getting the Date back from the Query, then change the Date "time" value, and then retrieve the Company to see if it was updated ? (this would then be consistent with the other test in that file which does that with an embedded field).