Re: FieldsOfDouble problem
On Wednesday 18 May 2005 06:01, Craig Russell wrote:
We decided to use these values for double in the AllTypes class:
public static final double DOUBLE_SMALLEST = -9.9;
public static final double DOUBLE_LARGEST = 9.9;
public static final double[] double_values =
{ DOUBLE_SMALLEST, DOUBLE_LARGEST, 0.0, 100.0, 100.0,
5000.0, -234234.234, 10.0, 350.5, -25.5 };
I'd be happy to use DOUBLE_LARGEST and DOUBLE_SMALLEST from AllTypes.
What do you all think?
May I suggest that 0.1 and -0.1 are included in the suite of numbers??
Over the years, they have been involved in a lot of rounding issues (granted;
because people errenously use floats and doubles for monetary and other
fixed-point decimal numbers) and I would be happy if the expected behaviour
is documented in tests.
Cheers
Niclas
Re: Patch for JDO JIRA issue JDO-45
Michael, I tested the patch on the tck20 project and it works fine. I did maven -o clean, maven -o database, and maven -o -Dtest=query.NavigationThroughACollectionField runtck.jdorisingle, and the test found company.xml. Thanks very much, Michelle Michael Bouschen wrote: Hi Michelle, I looked into the JIRA issue JDO-45: Need to do full build to get company.xml copied to target dir http://issues.apache.org/jira/browse/JDO-45 I propose to rename the maven goal copyloggingprops to copyprops and add copying the company.xml file to it. Attached you find a patch including this change for tck11 and tck20. You can run the patch by calling 'patch -p0 JDO-45.patch' in the directory trunk. Please let me know whether it works for you, then I can check in the change. Regards Michael
Re: FieldsOfDouble problem
Hi Niclas,
Your idea seems reasonable. I believe we already have a rounding
algorithm in the tests, so putting in some explicit known tricky cases
would be a good test.
Craig
On May 17, 2005, at 10:37 PM, Niclas Hedhman wrote:
On Wednesday 18 May 2005 06:01, Craig Russell wrote:
We decided to use these values for double in the AllTypes class:
public static final double DOUBLE_SMALLEST = -9.9;
public static final double DOUBLE_LARGEST = 9.9;
public static final double[] double_values =
{ DOUBLE_SMALLEST, DOUBLE_LARGEST, 0.0, 100.0, 100.0,
5000.0, -234234.234, 10.0, 350.5, -25.5 };
I'd be happy to use DOUBLE_LARGEST and DOUBLE_SMALLEST from AllTypes.
What do you all think?
May I suggest that 0.1 and -0.1 are included in the suite of numbers??
Over the years, they have been involved in a lot of rounding issues
(granted;
because people errenously use floats and doubles for monetary and other
fixed-point decimal numbers) and I would be happy if the expected
behaviour
is documented in tests.
Cheers
Niclas
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
Re: Patch for JDO JIRA issue JDO-45
Hi Michelle, thanks for testing. I checked in the changes and set the JIRA issue to fixed. Regards Michael Michael, I tested the patch on the tck20 project and it works fine. I did maven -o clean, maven -o database, and maven -o -Dtest=query.NavigationThroughACollectionField runtck.jdorisingle, and the test found company.xml. Thanks very much, Michelle Michael Bouschen wrote: Hi Michelle, I looked into the JIRA issue JDO-45: Need to do full build to get company.xml copied to target dir http://issues.apache.org/jira/browse/JDO-45 I propose to rename the maven goal copyloggingprops to copyprops and add copying the company.xml file to it. Attached you find a patch including this change for tck11 and tck20. You can run the patch by calling 'patch -p0 JDO-45.patch' in the directory trunk. Please let me know whether it works for you, then I can check in the change. Regards Michael -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
Hi, Geoff, I'm not really sure of the purpose of JDOTCKTestCases.list. I hope Michael can explain this. In fact if you run the runtck or runtck.jdori targets, they read allTests.list. When I want to run a shorter set, I keep a copy of allTests.list and delete entries to run only the set that I want. Do we need to have an exclude feature like JavaTest? -- Michelle Geoff hendrey wrote: OK, so am am able to run the tck11 against JDOMax. There are two files in test/conf that seem to enumerate the test cases: allTests.list and JDOTCKTestCases.list. Why 2 files? What is the recommended way to have an exclude list (JavaTest parlance). I'm assuming I just comment the tests out in JDOTCKTestCases.list and leave allTests.list untouched. That right? -geoff --- Michelle Caisse [EMAIL PROTECTED] wrote: Hi, Geoff, All you need to do is check out the jdo project and build the subprojects in the correct order. You will get six subprojects from the jdo subversion repository: api11 api20 btree ri11 tck11 tck20 To get the btree jar in your local repository with the appropriate name you just do maven build in jdo/trunk/btree. It seems that we need to add information to README.txt regarding dependencies in building the subprojects, e.g. you must build btree before building tck11, ... Hope this helps, Michelle Geoff hendrey wrote: I'm trying to run the tck11 enhance goal. There is a dependency on jdo-btree-SNAPSHOT. When I try to execute the three CVS commands to get the code, I succesfully get org\netbeans\mdr\persistence package, but the btreeimpl subpackage appears to not exist. If I create the btreeimpl subpackage by hand, and execute the cvs update, it zaps the btreeimpl folder, so I take it it really does not exist in the cvs repository. Thus, I am stuck. In my opinion, it would be a good idea to ship a prebuilt, local maven repository, configured with all the jars. Or at least make this maven repository available for download. Then you can set your project.properties to simply point to a local repository. Actually relying on maven to download jars and/or source almost never works, especially if you specify head snapshot as opposed to a specific revision. my $0.02. So can somebody send me the jdo-btree-SNAPSHOT.jar? -geoff --- Michelle Caisse [EMAIL PROTECTED] wrote: Hi, We will have our regular meeting Friday, May 13 at 9 am PST to discuss JDO TCK issues and status. Dial-in numbers are: 866 230-6968 294-0479# International: +1 865 544-7856 Agenda: XML Schema (Brian T - specifics on orm dtd issues, Craig - dtd issues fixed?) JDO API release on ibiblio (Brian T, Craig) Detached objects (Matthew) Test development status (Michelle) Apache nightly builds (Brian) Other issues and status (any and all) -- Michelle Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
my old TCK notes
These are notes I gathered from the last version of the TCK I ran (not what I just got from Apache, but maybe some of the problems remain, we'll see). These are notes on the test source code itself. I'm not looking for any feedback on this, jut thought I would toss it out there. Package: com.sun.jdotck.api.PersistenceManager == [test class = GetObjectIdClass] contains hardcoded reference to RI's OID class. c1.getName().equals(com.sun.jdori.fostore.OID) This causes non-RI to wrongly fail. [test class = ConcurrentPersistenceManagerSameClasses] Does not properly cleanup PCPoint and PCRect objects. COnsequently, if the test is run more than once, it fails the second time. The reason for failure is because the findPoint method issues a jdo query, and uses the first object returned by the query's iterator. However, there may be multiple objects in the iterator. The test then goes on to compare the JAVA identity of said first object with the JAVA identity of the object made persistent earlier in the transaction. This leads to a failure with a message: Found PCPoint: 110, 120 Expected: 110, 120 This test would be fixed by deleting all objects matching the query BEFORE doing the first insert, or by changing the test comparison from JAVA identity to 110==p11a.getX() 120==p11a.getY() [test = OneInstanceOfObjectPerPersistenceManager] this test cannot be run twice in a row without clearing the database. Query findPoint (int x, int y) will simply find a point from a previous run. Since we're using datastore identity, the object retrieved from the query will be different since it has a different database pk. this results in Failed. Assertion A5.4-2 failed; query results differ [test = RefreshSideEffects] While not stricktly a bug, this test cannot be run twice in a row from the same JVM. This is because PersistenceCapable n1 is declared as static. The second time the test is run, makePersistent(n1) is called on a different persistence manager, while n1 remains in the cache of the first pm. This is illegal. This problem also manifests itself in all tests begining with Refresh. Package: com.sun.jdotck.api.InstanceCallbacks = [test class = CallingJdoPreClear] in InstanceCallbackClass.jdoPreClear the following line causes a NullPointerException because children is null: code ... numberOfChildren[intValue] = children.size(); ... /code children is not in the default-fetch-group and never gets loaded within the transaction for the PC primaryObj. The touchFields method never touches primaryObj.children, thus it remains null, having been set null in the transition to HOLLOW caused by the prior commit. Because jdoPreClear is not modified by the enhancer, children does not get loaded when jdoPreClear is called and the NullPointerException is thrown. This could be fixed by modifying the instanceCallbacks.jdo meta- data to add default-fetch-group=true for the field 'children'. package: com.sun.jdotck.models.company === [test class = Company] in constructor, parameter 'addr' is not assigned to instance variable 'address' code address = address /code should be changed to this.address = addr; package: com.sun.jdotck.models.fieldtypes === [test class = TestFieldsOfObject] The default value for Object0 is null. When the test forces garbage collection via System.gc(), the PC is garbage collected. When the PC is materialized from the datastore on getObjectById, a new instance of the PC is constructed. Because Object0 is not persistent, val assumes null default value. This causes a null pointer exception when !val.equals(startValue) is evaluated. The solution is to properly set the value of isPersistent[0] to false. This test incorrectly has set isPersistent[0] to true. If the value of isPersistent[0] is set to false, the offending block of code is correctly skiped and the null pointer avoided. The same error will be caused for several non-persistent fields. All of the following indexes of isPersistent should be false, not true: 0,16,36,52,72,88,108,124 [test class = TestFieldsOfSimpleInterface] The problem is identical to that of TestFieldsOfObject. All of the following indexes of isPersistent should be false, not true: 0,16,36,52,72,88,108,124 [test class = TestCollectionCollections] Should not use Vector, since application is not required to support Collection or Set unless they reference a HashSet. Causes a ClassCastException to be thrown. package: com.sun.jdotck.models.inheritance === [test class =
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
OK, so am am able to run the tck11 against JDOMax. There are two files in test/conf that seem to enumerate the test cases: allTests.list and JDOTCKTestCases.list. Why 2 files? What is the recommended way to have an exclude list (JavaTest parlance). I'm assuming I just comment the tests out in JDOTCKTestCases.list and leave allTests.list untouched. That right? -geoff --- Michelle Caisse [EMAIL PROTECTED] wrote: Hi, Geoff, All you need to do is check out the jdo project and build the subprojects in the correct order. You will get six subprojects from the jdo subversion repository: api11 api20 btree ri11 tck11 tck20 To get the btree jar in your local repository with the appropriate name you just do maven build in jdo/trunk/btree. It seems that we need to add information to README.txt regarding dependencies in building the subprojects, e.g. you must build btree before building tck11, ... Hope this helps, Michelle Geoff hendrey wrote: I'm trying to run the tck11 enhance goal. There is a dependency on jdo-btree-SNAPSHOT. When I try to execute the three CVS commands to get the code, I succesfully get org\netbeans\mdr\persistence package, but the btreeimpl subpackage appears to not exist. If I create the btreeimpl subpackage by hand, and execute the cvs update, it zaps the btreeimpl folder, so I take it it really does not exist in the cvs repository. Thus, I am stuck. In my opinion, it would be a good idea to ship a prebuilt, local maven repository, configured with all the jars. Or at least make this maven repository available for download. Then you can set your project.properties to simply point to a local repository. Actually relying on maven to download jars and/or source almost never works, especially if you specify head snapshot as opposed to a specific revision. my $0.02. So can somebody send me the jdo-btree-SNAPSHOT.jar? -geoff --- Michelle Caisse [EMAIL PROTECTED] wrote: Hi, We will have our regular meeting Friday, May 13 at 9 am PST to discuss JDO TCK issues and status. Dial-in numbers are: 866 230-6968 294-0479# International: +1 865 544-7856 Agenda: XML Schema (Brian T - specifics on orm dtd issues, Craig - dtd issues fixed?) JDO API release on ibiblio (Brian T, Craig) Detached objects (Matthew) Test development status (Michelle) Apache nightly builds (Brian) Other issues and status (any and all) -- Michelle Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
