[jira] Commented: (JDO-402) checkRemoveGroup - removeGroup should be before getGroups
[ http://issues.apache.org/jira/browse/JDO-402?page=comments#action_12424399 ] Andy Jefferson commented on JDO-402: The spec isnt totally silent (12.7.5 comment line in the code for getGroups). Erik asked the question on the mailing list on 15th Feb 2006, and a knowledgeable person replied that it is immutable, see http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200602.mbox/[EMAIL PROTECTED] checkRemoveGroup - removeGroup should be before getGroups - Key: JDO-402 URL: http://issues.apache.org/jira/browse/JDO-402 Project: JDO Issue Type: Bug Components: tck20 Affects Versions: JDO 2 final Reporter: Ilan Kirsh Assigned To: Craig Russell Fix For: JDO 2 maintenance release 1 Attachments: JDO-402.patch In org.apache.jdo.tck.api.persistencemanager.fetchplan.FetchPlanInterface, lines 281-282, it probably has to be: fp.removeGroup(default); Collection groups = fp.getGroups(); Instead of: Collection groups = fp.getGroups(); fp.removeGroup(default); -- 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-403) JDO2 Annotations
JDO2 Annotations Key: JDO-403 URL: http://issues.apache.org/jira/browse/JDO-403 Project: JDO Issue Type: New Feature Components: api20 Affects Versions: JDO 2 final Reporter: Andy Jefferson Fix For: JDO 2 maintenance release 1 Attachments: annotations.jar It would be desirable for JDO2 to have its own set of annotations. We have developed a set within JPOX that would likely serve as a starting point for such a set. In my opinion they should be 1. Split into javax.jdo.annotations.jdo and javax.jdo.annotations.orm 2. Move ORM attributes from some of the JDO annotations and have a ORM annotation. -- 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-392) Deletion of objects when foreign-key is present : unexpected DB exceptions now handled
Deletion of objects when foreign-key is present : unexpected DB exceptions now handled -- Key: JDO-392 URL: http://issues.apache.org/jira/browse/JDO-392 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 final Reporter: Andy Jefferson When I change JPOX to check for foreign-key constraints and when deleting an object with a FK present to just leave it to the DB to decide what to do (based on the specified FK) the DB throws exceptions. Such as [java] 1) test(org.apache.jdo.tck.extents.CloseAll)javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM datastoreidentity0.PERSONS WHERE DATASTORE_IDENTITY=? [java] at org.jpox.store.rdbms.request.DeleteRequest.execute(DeleteRequest.java:274) [java] at org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2495) [java] at org.jpox.store.StoreManager.delete(StoreManager.java:902) [java] at org.jpox.state.StateManagerImpl.internalDeletePersistent(StateManagerImpl.java:4206) [java] at org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4161) [java] at org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1393) [java] at org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1404) [java] at org.apache.jdo.tck.extents.ExtentTest.deleteEmployee(ExtentTest.java:200) [java] at org.apache.jdo.tck.extents.CloseAll.test(CloseAll.java:61) [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) [java] NestedThrowablesStackTrace: [java] ERROR 23503: DELETE on table 'PERSONS' caused a violation of foreign key constraint 'PERS_MANAGER_FK' for key (885). The statement has been rolled back. [java] at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) [java] at org.apache.derby.impl.sql.execute.ReferencedKeyRIChecker.doCheck(Unknown Source) [java] at org.apache.derby.impl.sql.execute.RISetChecker.doPKCheck(Unknown Source) [java] at org.apache.derby.impl.sql.execute.DeleteResultSet.runFkChecker(Unknown Source) [java] at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) [java] at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) [java] at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.execute(NewProxyPreparedStatement.java:911) [java] at org.jpox.store.rdbms.ParamLoggingPreparedStatement.execute(ParamLoggingPreparedStatement.java:213) [java] at org.jpox.store.rdbms.request.Request.executeUpdate(Request.java:88) [java] at org.jpox.store.rdbms.request.DeleteRequest.execute(DeleteRequest.java:260) [java] at org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2495) [java] at org.jpox.store.StoreManager.delete(StoreManager.java:902) [java] at org.jpox.state.StateManagerImpl.internalDeletePersistent(StateManagerImpl.java:4206) [java] at org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4161) [java] at org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1393) [java] at org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1404) [java] at org.apache.jdo.tck.extents.ExtentTest.deleteEmployee(ExtentTest.java:200) [java] at org.apache.jdo.tck.extents.CloseAll.test(CloseAll.java:61) [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) The deletion of objects should be handled by the TCK or better defined. Alternatively the JDO2 spec should define
[jira] Updated: (JDO-392) Deletion of objects when foreign-key is present : unexpected DB exceptions not handled
[ http://issues.apache.org/jira/browse/JDO-392?page=all ] Andy Jefferson updated JDO-392: --- Summary: Deletion of objects when foreign-key is present : unexpected DB exceptions not handled (was: Deletion of objects when foreign-key is present : unexpected DB exceptions now handled) Deletion of objects when foreign-key is present : unexpected DB exceptions not handled -- Key: JDO-392 URL: http://issues.apache.org/jira/browse/JDO-392 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 final Reporter: Andy Jefferson When I change JPOX to check for foreign-key constraints and when deleting an object with a FK present to just leave it to the DB to decide what to do (based on the specified FK) the DB throws exceptions. Such as [java] 1) test(org.apache.jdo.tck.extents.CloseAll)javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM datastoreidentity0.PERSONS WHERE DATASTORE_IDENTITY=? [java] at org.jpox.store.rdbms.request.DeleteRequest.execute(DeleteRequest.java:274) [java] at org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2495) [java] at org.jpox.store.StoreManager.delete(StoreManager.java:902) [java] at org.jpox.state.StateManagerImpl.internalDeletePersistent(StateManagerImpl.java:4206) [java] at org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4161) [java] at org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1393) [java] at org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1404) [java] at org.apache.jdo.tck.extents.ExtentTest.deleteEmployee(ExtentTest.java:200) [java] at org.apache.jdo.tck.extents.CloseAll.test(CloseAll.java:61) [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) [java] NestedThrowablesStackTrace: [java] ERROR 23503: DELETE on table 'PERSONS' caused a violation of foreign key constraint 'PERS_MANAGER_FK' for key (885). The statement has been rolled back. [java] at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) [java] at org.apache.derby.impl.sql.execute.ReferencedKeyRIChecker.doCheck(Unknown Source) [java] at org.apache.derby.impl.sql.execute.RISetChecker.doPKCheck(Unknown Source) [java] at org.apache.derby.impl.sql.execute.DeleteResultSet.runFkChecker(Unknown Source) [java] at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) [java] at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) [java] at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.execute(NewProxyPreparedStatement.java:911) [java] at org.jpox.store.rdbms.ParamLoggingPreparedStatement.execute(ParamLoggingPreparedStatement.java:213) [java] at org.jpox.store.rdbms.request.Request.executeUpdate(Request.java:88) [java] at org.jpox.store.rdbms.request.DeleteRequest.execute(DeleteRequest.java:260) [java] at org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2495) [java] at org.jpox.store.StoreManager.delete(StoreManager.java:902) [java] at org.jpox.state.StateManagerImpl.internalDeletePersistent(StateManagerImpl.java:4206) [java] at org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4161) [java] at org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1393) [java] at org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1404) [java] at org.apache.jdo.tck.extents.ExtentTest.deleteEmployee(ExtentTest.java:200) [java] at org.apache.jdo.tck.extents.CloseAll.test(CloseAll.java:61) [java] at
[jira] Commented: (JDO-386) All distributions (source and binary) need to include NOTICE file
[
http://issues.apache.org/jira/browse/JDO-386?page=comments#action_12416054 ]
Andy Jefferson commented on JDO-386:
Hi Craig,
what we do with JPOX to get it in the jar is add it in the resources section
under build in project.xml like this
build
sourceDirectorysrc/java/sourceDirectory
resources
resource
directory${basedir}/../directory
includes
includeNOTICE.txt/include
/includes
/resource
/resources
and to get it in the distribution (maven dist) we add this to maven.xml
preGoal name=dist:build-src
ant:copy
todir=${maven.build.dir}/${maven.final.name}/src/${maven.final.name}
ant:fileset file=${basedir}/../NOTICE.txt /
/ant:copy
/preGoal
We just put the LICENSE.txt, NOTICE.txt at the top level and then refer to them
in the project.properties in each subproject
Not sure how that fits in with how you're doing it in Apache JDO, but hopefully
gives you some ideas.
All distributions (source and binary) need to include NOTICE file
-
Key: JDO-386
URL: http://issues.apache.org/jira/browse/JDO-386
Project: JDO
Type: Bug
Components: api20, tck20
Versions: JDO 2 final
Reporter: Craig Russell
Fix For: JDO 2 maintenance release 1
The distributions need to include a NOTICE file in the same directory as the
LICENSE file. Both the source and binary distributions need this file.
For details, see http://www.apache.org/dev/apply-license.html#new summarized
as follows:
A NOTICE file should be included in the same directory as the LICENSE file.
The NOTICE should include only those attribution notices that are required by
any part of the entire distribution. For Apache projects and those
redistributing ASF software, the NOTICE file must contain the sentence:
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
The license is applied to each source file (code and documentation, but
excluding the LICENSE and NOTICE files) by including a short copyright notice
at the top, as demonstrated by the boilerplate notice provided in the
appendix.
I've filed this under tck20 and api20 but it applies to all Apache
distributions.
--
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-378) SQL query : executeWithMap test
SQL query : executeWithMap test --- Key: JDO-378 URL: http://issues.apache.org/jira/browse/JDO-378 Project: JDO Type: Test Components: tck20 Versions: JDO 2 final Reporter: Andy Jefferson Priority: Minor Fix For: JDO 2 maintenance release 1 SQL queries when executed using executeWithMap() should check that the Map contains keys of type Integer and with values starting at 1. There don't seem to be any tests for SQL Query.executeWithMap in the TCK (as I just found out performing such a query with JPOX and getting an incorrect result) and so would be a good addition for any maintenance release. JPOX CVS now supports this behaviour btw. -- 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-375) Company model tables are not fully cleaned up
[ http://issues.apache.org/jira/browse/JDO-375?page=all ] Andy Jefferson updated JDO-375: --- Attachment: jpox-enhancer-SNAPSHOT.jar jpox-SNAPSHOT.jar Attached are jars built from JPOX CVS HEAD. I can confirm the fix works and have run the complete TCK twice through with success. Good work! Company model tables are not fully cleaned up - Key: JDO-375 URL: http://issues.apache.org/jira/browse/JDO-375 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 rc1 Reporter: Erik Bengtson Assignee: Erik Bengtson Fix For: JDO 2 final Attachments: JDO-375-2.patch, JDO-375-fknames.patch, JDO-375.patch, jpox-SNAPSHOT.jar, jpox-enhancer-SNAPSHOT.jar Tables from company model does not appear to be clean after run. I can't say if this is a JPOX or TCK issue, because I did not dig into the issue. On second run, exceptions are like 1) test(org.apache.jdo.tck.api.persistencemanager.extent.GetExtentWithInstancesMadePersistentViaReachability)javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO applicationidentity0.COMPANIES (NAME,FOUNDEDDATE,ADDRID,CITY,COUNTRY,STATE,STREET,ZIPCODE,ID,DISCRIMINATOR) VALUES (?,?,?,?,?,?,?,?,?,?) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:393) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2171) at org.jpox.store.StoreManager.insert(StoreManager.java:757) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3456) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3429) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1150) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1205) at org.apache.jdo.tck.api.persistencemanager.extent.GetExtentWithInstancesMadePersistentViaReachability.createObjects(GetExtentWithInstancesMadePersistentViaReachability.java:72) at org.apache.jdo.tck.api.persistencemanager.extent.GetExtentWithInstancesMadePersistentViaReachability.test(GetExtentWithInstancesMadePersistentViaReachability.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:237) at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:107) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:147) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:122) NestedThrowablesStackTrace: ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'COMPS_PK' defined on 'COMPANIES'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown Source) at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.execute(NewProxyPreparedStatement.java:911) at org.jpox.store.rdbms.ParamLoggingPreparedStatement.execute(ParamLoggingPreparedStatement.java:212) at org.jpox.store.rdbms.request.Request.executeUpdate(Request.java:88) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:267) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2171) at org.jpox.store.StoreManager.insert(StoreManager.java:757) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3456) at
[jira] Commented: (JDO-298) Update javadoc to be consistent with 2.0-beta
[ http://issues.apache.org/jira/browse/JDO-298?page=comments#action_12372633 ] Andy Jefferson commented on JDO-298: Hi Michelle, thanks for updating the javadocs. Are you sure they reflect 2.0-final ? I looked at javax.jdo.FetchPlan and see that getGroups() returns a Collection in the javadocs, yet in the code for api20 it returns a Set. Update javadoc to be consistent with 2.0-beta - Key: JDO-298 URL: http://issues.apache.org/jira/browse/JDO-298 Project: JDO Type: Task Components: site and infrastructure Versions: JDO 2 beta Reporter: Andy Jefferson Assignee: Michelle Caisse Priority: Trivial Fix For: JDO 2 final The current linked javadoc on the Apache JDO site for JDO2 still has PM.attachCopy etc. It needs updating. If another release is coming up then could be done as part of that since its not of high priority -- 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-298) Update javadoc to be consistent with 2.0-beta
[ http://issues.apache.org/jira/browse/JDO-298?page=comments#action_12372639 ] Andy Jefferson commented on JDO-298: Hi Craig, Looks fine now! Thanks. Update javadoc to be consistent with 2.0-beta - Key: JDO-298 URL: http://issues.apache.org/jira/browse/JDO-298 Project: JDO Type: Task Components: site and infrastructure Versions: JDO 2 beta Reporter: Andy Jefferson Assignee: Michelle Caisse Priority: Trivial Fix For: JDO 2 final The current linked javadoc on the Apache JDO site for JDO2 still has PM.attachCopy etc. It needs updating. If another release is coming up then could be done as part of that since its not of high priority -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=comments#action_12372223 ] Andy Jefferson commented on JDO-347: No problem Martin. It should all be built into the current JPOX nightly build and passes for me with latest SVN TCK JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 rc1 Reporter: Martin Zaun Assignee: Andy Jefferson Fix For: JDO 2 final Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=comments#action_12372060 ] Andy Jefferson commented on JDO-347: With the latest integration of a fix for JDO-273, there's one lifecycle test failing: serialize with optimistic tx should leave the state unchanged (in contrast to a datastore tx, where serialize transitions hollow/persistent-nontransactional to persistent-clean). Great. That's what it used to do until 3 days ago when I changed it to match the test! Will change it back again JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 rc1 Reporter: Martin Zaun Assignee: Andy Jefferson Fix For: JDO 2 final Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=all ] Andy Jefferson resolved JDO-347: Resolution: Fixed Fixed in JPOX CVS JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 rc1 Reporter: Martin Zaun Assignee: Andy Jefferson Fix For: JDO 2 final Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=comments#action_12371852 ] Andy Jefferson commented on JDO-347: Test StateTransitions now passes with JPOX CVS JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Reporter: Martin Zaun Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=comments#action_12371865 ] Andy Jefferson commented on JDO-347: I would like some input into StateTransitionsReturnedObjects. Let's take this message :- [java] Assertions A5.9-1 through A5.5.8 (serialization, detachment, attachment) failed: [java] StateTransitionsReturnedObjects: datastore transaction; current state transient-clean [java] serialize with active tx returned instance in invalid state detached-clean; expected state transient Looking at the test it takes a transient-clean instance (in a txn) and serialises it and then deserialises the serialised object. The end result object will have the detached state present and no StateManager. Consequently it will be detached. Why is the expectation transient ? What am I missing ? ;-) JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Reporter: Martin Zaun Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=comments#action_12371779 ] Andy Jefferson commented on JDO-347: I would like to know what the StateTransitionsReturnedObjects tests are performing. They state errors like [java] Assertions A5.9-1 through A5.5.8 (serialization, detachment, attachment) failed: [java] StateTransitionsReturnedObjects: datastore transaction; current state transient-clean [java] serialize with active tx returned instance in invalid state detached-clean; expected state transient What is the serialization, detachment, attachment part of the message ? Is it that a transient-clean has been serialised, then detached, then attached and it ends up with detached-clean instead of expected transient ? Dumping all tests into one JUnit means that it is time consuming to debug such things, particularly in terms of locating the relevant part in the JPOX log. JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Reporter: Martin Zaun Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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-346) Cleanup and refactorize lifecycle tests StateTransitions and StateTransitionsReturnedObjects
[ http://issues.apache.org/jira/browse/JDO-346?page=comments#action_12371559 ] Andy Jefferson commented on JDO-346: When I do a clean check out and then run the TCK, when it is running lifecycle.conf I get an error Cannot find test class 'org.apache.jdo.tck.lifecycle.StateTransitionsReturnedObjects' No idea if this is what this particular JIRA is for, but seems an appropriate place to log the message ;-) Cleanup and refactorize lifecycle tests StateTransitions and StateTransitionsReturnedObjects Key: JDO-346 URL: http://issues.apache.org/jira/browse/JDO-346 Project: JDO Type: Improvement Components: tck20 Versions: JDO 2 final Reporter: Martin Zaun Priority: Trivial The fix for JDO-273 has introduced a large amount of code duplication between the lifecycle test classes StateTransitions and StateTransitionsReturnedObjects. Cleanup and refactorize (e.g. merge both classes into one, or extend one from the other, or pull out common code into a lifecycle test super class). -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=comments#action_12371574 ] Andy Jefferson commented on JDO-347: For information : JPOX CVS cuts the long list of failing transitions attached to this issue down to [java] Assertions A5.9-1 through A5.9-190 (StateTransitions) failed: [java] StateTransitions: optimistic transaction; current state hollow [java] makeTransient; unexpected exception caught: java.lang.ClassCastException [java] Assertions A5.9-1 through A5.9-190 (StateTransitions) failed: [java] StateTransitions: optimistic transaction; current state hollow [java] serialize with active tx transitioned instance to invalid state hollow; expected state persistent-clean [java] Assertions A5.9-1 through A5.9-190 (StateTransitions) failed: [java] StateTransitions: optimistic transaction; current state persistent-nontransactional [java] serialize with active tx transitioned instance to invalid state hollow; expected state persistent-clean JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Reporter: Martin Zaun Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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-347) JPOX fails some lifecycle tests
[ http://issues.apache.org/jira/browse/JDO-347?page=comments#action_12371594 ] Andy Jefferson commented on JDO-347: org.apache.jdo.tck.lifecycle.StateTransitionsReturnedObjects :- This test seems to think that calling detachCopy on a detached instance will return a DETACH_CLEAN. I personally would defer to 12.6.8 Explicit Detachment of the JDO2 spec specIf the parameter instance (to detachCopy) is detached, then JDOUserException is thrown./spec JPOX fails some lifecycle tests --- Key: JDO-347 URL: http://issues.apache.org/jira/browse/JDO-347 Project: JDO Type: Bug Components: tck20 Reporter: Martin Zaun Attachments: errors_state_transition_argument_instances.txt, errors_state_transition_returned_instances.txt The integration of fixes for JDO-273 and JDO-258 has added (and fixed) a number of lifecycle test cases that are failed by JPOX. See attached error messages. -- 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] 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] Created: (JDO-311) Inheritance3 : should check if the JDO implementation supports javax.jdo.option.mapping.RelationSubclassTable
Inheritance3 : should check if the JDO implementation supports javax.jdo.option.mapping.RelationSubclassTable --- Key: JDO-311 URL: http://issues.apache.org/jira/browse/JDO-311 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 beta Reporter: Andy Jefferson The inheritance3 test should check whether PMF.supportedOptions contains javax.jdo.option.mapping.RelationSubclassTable before running the test. JPOX doesn't support this option yet the test still runs (and fails) -- 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-306) Add makeTransient(Object, boolean) to PersistenceManager
Add makeTransient(Object, boolean) to PersistenceManager Key: JDO-306 URL: http://issues.apache.org/jira/browse/JDO-306 Project: JDO Type: Task Components: api20 Versions: JDO 2 beta Reporter: Andy Jefferson The JDO2 spec should be updated with the overloaded method makeTransient(Object pc, boolean useFetchPlan) which will allow the make transient of all instances reachable from the current instance using the current fetch plan. -- 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-288) Update DTD, XSD, and FetchPlan.java for fetch plan updates
[ http://issues.apache.org/jira/browse/JDO-288?page=comments#action_12366540 ] Andy Jefferson commented on JDO-288: Hi Michael, JPOX CVS has those methods. Check in at will. The latest downloadable JPOX nightly build has an error in the scope of some of the methods - which is fixed in CVS and will be in next build 16/02/2006 or later. Update DTD, XSD, and FetchPlan.java for fetch plan updates -- Key: JDO-288 URL: http://issues.apache.org/jira/browse/JDO-288 Project: JDO Type: Bug Components: api20 Versions: JDO 2 beta Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 rc1 Attachments: patch.txt The latest spec calls for changes to the metadata regarding fetch groups. The fetch-depth attribute of field has been removed, replaced with the recursion-depth attribute. Additionally, the FetchPlan interface has been changed by adding several methods: get/setDetachmentRoots, get/setDetachmentRootClasses, get/setMaxFetchDepth -- 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-306) Add makeTransient(Object, boolean) to PersistenceManager
[ http://issues.apache.org/jira/browse/JDO-306?page=comments#action_12366594 ] Andy Jefferson commented on JDO-306: JPOX CVS has the new methods. The latest nightly build should be fine. Add makeTransient(Object, boolean) to PersistenceManager Key: JDO-306 URL: http://issues.apache.org/jira/browse/JDO-306 Project: JDO Type: Task Components: api20 Versions: JDO 2 beta Reporter: Andy Jefferson Attachments: makeTransient.patch, pm_patch.txt, pm_patch_2.txt The JDO2 spec should be updated with the overloaded method makeTransient(Object pc, boolean useFetchPlan) which will allow the make transient of all instances reachable from the current instance using the current fetch plan. -- 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-298) Update javadoc to be consistent with 2.0-beta
Update javadoc to be consistent with 2.0-beta - Key: JDO-298 URL: http://issues.apache.org/jira/browse/JDO-298 Project: JDO Type: Task Components: site and infrastructure Versions: JDO 2 beta Reporter: Andy Jefferson Priority: Trivial The current linked javadoc on the Apache JDO site for JDO2 still has PM.attachCopy etc. It needs updating. If another release is coming up then could be done as part of that since its not of high priority -- 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-285) Fix list of teardown classes in company model reader.
[ http://issues.apache.org/jira/browse/JDO-285?page=comments#action_12365104 ] Andy Jefferson commented on JDO-285: Hi Michael, can you please provide a cut down guide on what the first of these problems is? What are you calling exactly ? The stack trace says rollback !? (but what caused that?) On which class ? (Employee ?) and what inheritance does it have ? [I don't want to get into taking patches] What I'm getting at is, can I get a simplified testcase that reproduces it ? ... debugging through a large company model just to find something is time-consuming :-( Can it be cut down to just 3 or 4 classes, and then call pm.deletePersistentAll or something ? Fix list of teardown classes in company model reader. - Key: JDO-285 URL: http://issues.apache.org/jira/browse/JDO-285 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Michael Watzek Attachments: JDO-285.patch The list of teardown classes in company model should not contain subclasses of inheritance hierarchies insurance and person. In t-conference, Jan 27, we agreed that the correct order is: Insurance.class, Person.class, Department.class, Company.class, Project.class. -- 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-289) Regression: all tests fail with jpox-c3p0-SNAPSHOT.jar
[ http://issues.apache.org/jira/browse/JDO-289?page=comments#action_12365046 ] Andy Jefferson commented on JDO-289: FYI. The C3P0 (and DBCP) plugins were updated to add an extra parameter to their constructor, allowing specification of a configuration file. The latest JPOX jar was needed to use the new calling sequence - which is why it didnt work til you had the jpox jar. Need to update our overnight build process so they are put on the download site att he same time. Regression: all tests fail with jpox-c3p0-SNAPSHOT.jar -- Key: JDO-289 URL: http://issues.apache.org/jira/browse/JDO-289 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson Priority: Critical With the latest build of the jpox-c3p0 jar file, all tests give the following error. The beta version works fine. test(org.apache.jdo.tck.transactions.SetOptimisticDuringTransaction)javax.jdo.JDOFatalInternalExcept java.lang.String, java.lang.String, java.lang.String, java.lang.String) plugin to create a ConnectionPool gave an [java] at org.jpox.AbstractPersistenceManagerFactory.freezeConfiguration(AbstractPersistenceManagerFactory [java] at org.jpox.PersistenceManagerFactoryImpl.getPersistenceManagerFactory(PersistenceManagerFactoryImp [java] at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:515) [java] at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:466) [java] at org.apache.jdo.tck.JDO_Test.getPMF(JDO_Test.java:419) [java] at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:186) [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:203) [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) [java] NestedThrowablesStackTrace: [java] java.lang.NoSuchMethodException: org.jpox.c3p0.C3P0DataSourceFactory.makePooledDataSource(java.lang.Stri [java] at java.lang.Class.getMethod(Class.java:978) [java] at org.jpox.AbstractPersistenceManagerFactory.freezeConfiguration(AbstractPersistenceManagerFactory [java] at org.jpox.PersistenceManagerFactoryImpl.getPersistenceManagerFactory(PersistenceManagerFactoryImp [java] at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:515) [java] at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:466) [java] at org.apache.jdo.tck.JDO_Test.getPMF(JDO_Test.java:419) [java] at org.apache.jdo.tck.JDO_Test.setUp(JDO_Test.java:186) [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:203) [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) [java] at org.apache.jdo.tck. util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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] Assigned: (JDO-249) JPOX throws JDOFatalInternalException for queries using new MyClass(...) in result clauses
[ http://issues.apache.org/jira/browse/JDO-249?page=all ] Andy Jefferson reassigned JDO-249: -- Assign To: Andy Jefferson (was: Erik Bengtson) JPOX throws JDOFatalInternalException for queries using new MyClass(...) in result clauses Key: JDO-249 URL: http://issues.apache.org/jira/browse/JDO-249 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Test case ResultClassRequirements fails for the query below. The query has a constructor call in the result clause. 14:23:07,781 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT new LongString(personid, lastname) FROM org.apache.jdo.tck.pc.company.FullTimeEmployee IMPORTS import org.apache.jdo.tck.query.result.classes.LongString; 14:23:07,781 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: javax.jdo.JDOFatalInternalException: The expression NewObjectExpression is not supported in results. at org.jpox.store.query.ResultExpressionsQueryable.newResultObjectFactory(ResultExpressionsQueryable.java:251) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:642) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:946) at org.apache.jdo.tck.query.result.ResultClassRequirements.executeQuery(ResultClassRequirements.java:464) at org.apache.jdo.tck.query.result.ResultClassRequirements.testConstructor(ResultClassRequirements.java:436) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-249) JPOX throws JDOFatalInternalException for queries using new MyClass(...) in result clauses
[ http://issues.apache.org/jira/browse/JDO-249?page=all ] Andy Jefferson resolved JDO-249: Resolution: Fixed Gone to meet its maker. Fixed in JPOX CVS - builds dated 09/01/2006 or later should have this. JPOX throws JDOFatalInternalException for queries using new MyClass(...) in result clauses Key: JDO-249 URL: http://issues.apache.org/jira/browse/JDO-249 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Test case ResultClassRequirements fails for the query below. The query has a constructor call in the result clause. 14:23:07,781 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT new LongString(personid, lastname) FROM org.apache.jdo.tck.pc.company.FullTimeEmployee IMPORTS import org.apache.jdo.tck.query.result.classes.LongString; 14:23:07,781 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: javax.jdo.JDOFatalInternalException: The expression NewObjectExpression is not supported in results. at org.jpox.store.query.ResultExpressionsQueryable.newResultObjectFactory(ResultExpressionsQueryable.java:251) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:642) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:946) at org.apache.jdo.tck.query.result.ResultClassRequirements.executeQuery(ResultClassRequirements.java:464) at org.apache.jdo.tck.query.result.ResultClassRequirements.testConstructor(ResultClassRequirements.java:436) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-263) TestArrayCollections: Field ArrayOfBigDecimal12 is stored incorrectly
[ http://issues.apache.org/jira/browse/JDO-263?page=all ] Andy Jefferson resolved JDO-263: Resolution: Fixed Fixed in JPOX CVS - builds dated 08/01/2006 or later. :-) TestArrayCollections: Field ArrayOfBigDecimal12 is stored incorrectly - Key: JDO-263 URL: http://issues.apache.org/jira/browse/JDO-263 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson Attachments: jdo-263.patch test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)javax.jdo.JDOUserException: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 is declared as a reference type (interface/Object) but no implementation classes of java.lang.Object have been found! at org.jpox.metadata.MetaDataUtils.getImplementationNamesForReferenceField(MetaDataUtils.java:594) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForReferenceField(ColumnCreator.java:184) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:296) at org.jpox.store.rdbms.table.ColumnCreator.createColumns(ColumnCreator.java:95) at org.jpox.store.rdbms.table.ArrayTable.initialize(ArrayTable.java:83) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2404) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2033) at org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:1893) at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:479) at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:493) at org.jpox.store.rdbms.RDBMSManager.getDatastoreClass(RDBMSManager.java:766) at org.jpox.state.StateManagerImpl.populateStrategyFields(StateManagerImpl.java:781) at org.jpox.state.StateManagerImpl.init(StateManagerImpl.java:584) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1076) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1131) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:93) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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] Assigned: (JDO-247) JPOX must throw JDOUserException for queries using incompatible result classes.
[ http://issues.apache.org/jira/browse/JDO-247?page=all ] Andy Jefferson reassigned JDO-247: -- Assign To: Andy Jefferson (was: Erik Bengtson) JPOX must throw JDOUserException for queries using incompatible result classes. --- Key: JDO-247 URL: http://issues.apache.org/jira/browse/JDO-247 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Test case ResultClassRequirements fails because query compilation is expected to throw JDOUserException: The result clause and the result class are incompatible. 14:22:56,765 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT personid AS l, salary AS s INTO org.apache.jdo.tck.query.result.classes.LongString FROM org.apache.jdo.tck.pc.company.FullTimeEmployee 14:22:56,765 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw JDOUserException: null 14:22:56,765 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A14.6.12-1 (ResultClassRequirements) failed: Query compilation must throw JDOUserException: null at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878) at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) at org.apache.jdo.tck.query.result.ResultClassRequirements.testNegative(ResultClassRequirements.java:456) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-247) JPOX must throw JDOUserException for queries using incompatible result classes.
[ http://issues.apache.org/jira/browse/JDO-247?page=all ] Andy Jefferson resolved JDO-247: Resolution: Fixed Fixed in JPOX CVS - builds dated 08/01/2006 or later should have this. JPOX must throw JDOUserException for queries using incompatible result classes. --- Key: JDO-247 URL: http://issues.apache.org/jira/browse/JDO-247 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Test case ResultClassRequirements fails because query compilation is expected to throw JDOUserException: The result clause and the result class are incompatible. 14:22:56,765 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT personid AS l, salary AS s INTO org.apache.jdo.tck.query.result.classes.LongString FROM org.apache.jdo.tck.pc.company.FullTimeEmployee 14:22:56,765 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw JDOUserException: null 14:22:56,765 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A14.6.12-1 (ResultClassRequirements) failed: Query compilation must throw JDOUserException: null at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878) at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) at org.apache.jdo.tck.query.result.ResultClassRequirements.testNegative(ResultClassRequirements.java:456) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-251) JPOX generates illegal SQL for queries using COUNT(variable) in result clauses.
[ http://issues.apache.org/jira/browse/JDO-251?page=all ] Andy Jefferson resolved JDO-251: Resolution: Fixed Rest in Peace. Fixed in JPOX CVS - builds dated 08/01/2006 or later should have this fix. JPOX generates illegal SQL for queries using COUNT(variable) in result clauses. --- Key: JDO-251 URL: http://issues.apache.org/jira/browse/JDO-251 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Test case ResultExpressions fails for the query below. The query uses COUNT(variable) in the result clause. The variable is bound to a collection. 14:23:19,437 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT COUNT(project) FROM org.apache.jdo.tck.pc.company.Employee WHERE projects.contains(project) personid == 1 VARIABLES Project project 14:23:19,515 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: javax.jdo.JDODataStoreException: Error executing JDOQL query SELECT DISTINCT COUNT() FROM applicationidentity0.PERSONS THIS INNER JOIN applicationidentity0.PROJECT_MEMBER THIS_PROJECTS ON THIS_PROJECTS.MEMBER = THIS.PERSONID INNER JOIN applicationidentity0.PROJECTS UNBOUND_PROJECT ON UNBOUND_PROJECT.PROJID = THIS_PROJECTS.PROJID WHERE (THIS.DISCRIMINATOR = ? OR THIS.DISCRIMINATOR = ? OR THIS.DISCRIMINATOR = ?) AND THIS.PERSONID = 1 : Syntax error: Encountered ) at line 1, column 23. ERROR 42X01: Syntax error: Encountered ) at line 1, column 23. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190) at org.jpox.store.StatementText.prepareStatement(StatementText.java:199) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:678) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at org.apache.jdo.tck.query.result.ResultExpressions.executeQuery(ResultExpressions.java:483) at org.apache.jdo.tck.query.result.ResultExpressions.testCountVariable(ResultExpressions.java:410) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) . at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:747) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at
[jira] Commented: (JDO-263) TestArrayCollections: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 is declared as a reference type (interface/Object) but no implementation clas
[ http://issues.apache.org/jira/browse/JDO-263?page=comments#action_12361984 ] Andy Jefferson commented on JDO-263: You say that your patch changes the results to those you show in 04 Jan. Well if I round the numbers (that current SVN gives and that I quoted) to the same precision as what was expected I get the exact same number as the expected. I only have to look at the numbers to do that. For example if I take 64564645656.78656768798828125 and round it to the same precision as the expected (64564645656.78657 - i.e 5 decimal places) then I get 64564645656.78657. Where does your number come from ? Why it is different from other tests? I've no idea. I do know that storage of and retrieval of large floating point numbers is unreliable - see the issue about LessThanEquals and about Derby storing things in a seemingly odd way. The only difference here is that you have a serialised array of large floating point numbers, as opposed to a single column with a large floating point number in it. Consequently we have introduced serialisation, and arrays Why does the serialised BigDecimal fail ? see above. It is serialised. I still fail to see what JPOX is expected to do when the underlying datastore doesnt store floating points in a reliable way. TestArrayCollections: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 is declared as a reference type (interface/Object) but no implementation classes of java.lang.Object have been found! -- Key: JDO-263 URL: http://issues.apache.org/jira/browse/JDO-263 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson Attachments: jdo-263.patch test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)javax.jdo.JDOUserException: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 is declared as a reference type (interface/Object) but no implementation classes of java.lang.Object have been found! at org.jpox.metadata.MetaDataUtils.getImplementationNamesForReferenceField(MetaDataUtils.java:594) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForReferenceField(ColumnCreator.java:184) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:296) at org.jpox.store.rdbms.table.ColumnCreator.createColumns(ColumnCreator.java:95) at org.jpox.store.rdbms.table.ArrayTable.initialize(ArrayTable.java:83) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2404) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2033) at org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:1893) at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:479) at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:493) at org.jpox.store.rdbms.RDBMSManager.getDatastoreClass(RDBMSManager.java:766) at org.jpox.state.StateManagerImpl.populateStrategyFields(StateManagerImpl.java:781) at org.jpox.state.StateManagerImpl.init(StateManagerImpl.java:584) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1076) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1131) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:93) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-245) JPOX must throw JDOUserException for queries specifying having clause refering fields which are not part of the result clause.
[ http://issues.apache.org/jira/browse/JDO-245?page=comments#action_12361581 ] Andy Jefferson commented on JDO-245: I look at the test Having.testNegative and the query is now SELECT department, SUM(salary) FROM Employee GROUP BY department HAVING firstname What is this exactly supposed to test ? Is it testing that the having clause is a boolean expression (which it clearly isn't) ? Is it testing that a having field is not in the grouping ? The query in the original post had a having clause of firstname == 'emp1first'. Did someone change this for a reason ? JPOX must throw JDOUserException for queries specifying having clause refering fields which are not part of the result clause. -- Key: JDO-245 URL: http://issues.apache.org/jira/browse/JDO-245 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson The test case Having fails for the query below. Query compilation is expected to throw a JDOUserException because the having clause contains field firstname which is not part of the result clause. 14:22:53,437 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT department, SUM(salary) FROM org.apache.jdo.tck.pc.company.Employee GROUP BY department HAVING firstname == 'emp1First' 14:22:53,453 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw JDOUserException: null 14:22:53,453 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A14.6.10-2 (Having) failed: Query compilation must throw JDOUserException: null at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878) at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) at org.apache.jdo.tck.query.result.Having.testNegative(Having.java:120) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-245) JPOX must throw JDOUserException for queries specifying having clause refering fields which are not part of the result clause.
[ http://issues.apache.org/jira/browse/JDO-245?page=all ] Andy Jefferson resolved JDO-245: Resolution: Fixed Assign To: Andy Jefferson (was: Erik Bengtson) Thanks for your reply Michael. Let's leave the test as it is ;-) Now fixed in JPOX CVS - builds dated 04/01/2006 onwards have this. JPOX must throw JDOUserException for queries specifying having clause refering fields which are not part of the result clause. -- Key: JDO-245 URL: http://issues.apache.org/jira/browse/JDO-245 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson The test case Having fails for the query below. Query compilation is expected to throw a JDOUserException because the having clause contains field firstname which is not part of the result clause. 14:22:53,437 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT department, SUM(salary) FROM org.apache.jdo.tck.pc.company.Employee GROUP BY department HAVING firstname == 'emp1First' 14:22:53,453 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw JDOUserException: null 14:22:53,453 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A14.6.10-2 (Having) failed: Query compilation must throw JDOUserException: null at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878) at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) at org.apache.jdo.tck.query.result.Having.testNegative(Having.java:120) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-271) SingleStringQuery has a query accessing a field in a subclass
SingleStringQuery has a query accessing a field in a subclass - Key: JDO-271 URL: http://issues.apache.org/jira/browse/JDO-271 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assigned to: Michael Bouschen Bug JDO-270 was raised against JPOX for not detecting accesses to fields in subclasses, saying that it should raise an exception when it encounters such things. In which case can we please have the test SingleStringQuery fixed since it tries to access salary when using a candidate class of Person, which has no such salary (which is on FullTimeEmployee), or projects for that matter. Maybe change the candidate to FullTimeEmployee ? -- 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-270) JPOX must thrown JDOUserException for a query accessing a subclass field
[ http://issues.apache.org/jira/browse/JDO-270?page=all ] Andy Jefferson resolved JDO-270: Resolution: Fixed Another one bites the dust. Fixed in JPOX builds dated 04/01/2006 or later JPOX must thrown JDOUserException for a query accessing a subclass field Key: JDO-270 URL: http://issues.apache.org/jira/browse/JDO-270 Project: JDO Type: Bug Components: tck20 Reporter: Michael Bouschen Assignee: Andy Jefferson The query test class ResultExpressions now includes two negative tests both accessing unknow fields. JPOX does not throw an exception for the second test query accessing a field declared in the subclass of the candidate class: SELECT salary FROM org.apache.jdo.tck.pc.company.Employee The subclass FullTimeEmployee declares a field called salary. [java] Query compilation must throw JDOUserException: SELECT salary FROM org.apache.jdo.tck.pc.company.Employee [java] at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) [java] at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:917) [java] at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:880) [java] at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) [java] at org.apache.jdo.tck.query.result.ResultExpressions.testNegative(ResultExpressions.java:521) [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:120) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-248) JPOX generates illegal SQL for queries using result class java.util.Map.
[ http://issues.apache.org/jira/browse/JDO-248?page=comments#action_12361484 ] Andy Jefferson commented on JDO-248: The test has a query SELECT phoneNumbers FROM FullTimeEmployee INTO java.util.Map where phoneNumbers is a Map field. The test seems to think that selecting a field that is a Map will mean that this will be loaded into the result class Map for each result row. That is not my understanding of why java.util.Map was added to the JDO2 spec as a valid result class. It was added so that all fields/columns in the result spec can be added to the Map using the put(key, value) method with the key being the field name. Perhaps the test should be changed to select some real fields and then test that they have been loaded into the result Map correctly. JPOX generates illegal SQL for queries using result class java.util.Map. Key: JDO-248 URL: http://issues.apache.org/jira/browse/JDO-248 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test case ResultClassRequirements fails because JPOX generates illegal SQL for the query below. The query uses result class java.util.Map. The FROM caluse of the generated SQL is empty. 14:23:04,625 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT phoneNumbers INTO java.util.Map FROM org.apache.jdo.tck.pc.company.FullTimeEmployee 14:23:04,687 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: javax.jdo.JDODataStoreException: Error executing JDOQL query SELECT FROM applicationidentity0.PERSONS THIS WHERE THIS.DISCRIMINATOR = ? : Syntax error: Encountered FROM at line 1, column 9. ERROR 42X01: Syntax error: Encountered FROM at line 1, column 9. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190) at org.jpox.store.StatementText.prepareStatement(StatementText.java:199) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:678) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:946) at org.apache.jdo.tck.query.result.ResultClassRequirements.executeQuery(ResultClassRequirements.java:464) at org.apache.jdo.tck.query.result.ResultClassRequirements.testMap(ResultClassRequirements.java:424) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120)
[jira] Resolved: (JDO-253) JPOX generates illegal SQL for queries accessing fields of parameter in the result clause.
[ http://issues.apache.org/jira/browse/JDO-253?page=all ] Andy Jefferson resolved JDO-253: Resolution: Fixed Assign To: Andy Jefferson (was: Erik Bengtson) Fixed in JPOX CVS - builds 02/01/2006 or later. JPOX generates illegal SQL for queries accessing fields of parameter in the result clause. -- Key: JDO-253 URL: http://issues.apache.org/jira/browse/JDO-253 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Test case ResultExpressions fails for the query below. The query selects a field of a parameter in the result clause. The type of the parameter is a pc class. 14:23:30,734 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT project.projid FROM org.apache.jdo.tck.pc.company.Employee WHERE personid == 1 PARAMETERS Project project 14:23:30,796 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: javax.jdo.JDODataStoreException: Error executing JDOQL query SELECT FROM applicationidentity0.PERSONS THIS WHERE (THIS.DISCRIMINATOR = ? OR THIS.DISCRIMINATOR = ? OR THIS.DISCRIMINATOR = ?) AND THIS.PERSONID = 1 : Syntax error: Encountered FROM at line 1, column 9. ERROR 42X01: Syntax error: Encountered FROM at line 1, column 9. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190) at org.jpox.store.StatementText.prepareStatement(StatementText.java:199) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:678) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1153) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at org.apache.jdo.tck.query.result.ResultExpressions.executeQuery(ResultExpressions.java:483) at org.apache.jdo.tck.query.result.ResultExpressions.testNavigationalExpressionParameter(ResultExpressions.java:459) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) . at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:747) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1153) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at
[jira] Resolved: (JDO-240) JPOX throws JDOQLQuery$Compiler$ExpressionSyntaxException when DISTINCT is specified inside an aggregate function.
[ http://issues.apache.org/jira/browse/JDO-240?page=all ] Andy Jefferson resolved JDO-240: Resolution: Fixed Assign To: Andy Jefferson (was: Erik Bengtson) JPOX CVS now has support for COUNT(DISTINCT ...), AVG(DISTINCT ...), SUM(DISTINCT ...). Builds dated 01/01/2006 or later will have it. Happy New Year. Another 3 TCK tests now pass. JPOX throws JDOQLQuery$Compiler$ExpressionSyntaxException when DISTINCT is specified inside an aggregate function. -- Key: JDO-240 URL: http://issues.apache.org/jira/browse/JDO-240 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson The test case AggregateResult fails throwing the exception below when DISTINCT is specified inside an aggregate function. The exception is thrown for COUNT, SUM, and AVG. 14:22:43,625 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT AVG(DISTINCT manager.salary) FROM org.apache.jdo.tck.pc.company.FullTimeEmployee 14:22:43,625 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: org.jpox.store.query.JDOQLQuery$Compiler$ExpressionSyntaxException: ')' expected at character 14 in AVG(DISTINCT manager.salary) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1667) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1598) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1579) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1532) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1509) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1469) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1446) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1434) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1422) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1410) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1398) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1380) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1357) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpressionFromString(JDOQLQuery.java:1287) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpressionsFromString(JDOQLQuery.java:1341) at org.jpox.store.query.JDOQLQuery$Compiler.compileResult(JDOQLQuery.java:1044) at org.jpox.store.query.JDOQLQuery$Compiler.performCompile(JDOQLQuery.java:917) at org.jpox.store.query.JDOQLQuery$Compiler.executionCompile(JDOQLQuery.java:905) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:622) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:946) at org.apache.jdo.tck.query.result.AggregateResult.executeQuery(AggregateResult.java:627) at org.apache.jdo.tck.query.result.AggregateResult.testAVG(AggregateResult.java:613) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at
[jira] Resolved: (JDO-268) org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach fails with new definition of makePersistent instead of attachCopy
[ http://issues.apache.org/jira/browse/JDO-268?page=all ] Andy Jefferson resolved JDO-268: Resolution: Fixed attachCopy() just met a horrible death in JPOX CVS. There'll be a short service later to commemorate its brief life (don't send any flowers please), after which you can grab builds dated 30/12/2005 or later. Test now passes. org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach fails with new definition of makePersistent instead of attachCopy -- Key: JDO-268 URL: http://issues.apache.org/jira/browse/JDO-268 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assignee: Andy Jefferson The PersistenceManager method attachCopy was replaced by makePersistent. The test case now fails. -- 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-267) Query with alias result generates incorrect SQL
[
http://issues.apache.org/jira/browse/JDO-267?page=comments#action_12361314 ]
Andy Jefferson commented on JDO-267:
Any clue as to which TCK test this refers to ? The test class name would be
nice.
Query with alias result generates incorrect SQL
---
Key: JDO-267
URL: http://issues.apache.org/jira/browse/JDO-267
Project: JDO
Type: Bug
Components: tck20
Reporter: Craig Russell
Assignee: Andy Jefferson
This JDOQL query results in the wrong SQL:
/*UNIQUE*/ Boolean.FALSE,
/*RESULT*/ firstname AS firstName, lastname AS lastName,
/*INTO*/FullName.class,
/*FROM*/FullTimeEmployee.class,
/*EXCLUDE*/ Boolean.TRUE,
/*WHERE*/ salary 1000 projects.contains(p) +
p.budget limit,
/*VARIABLES*/ Project p,
/*PARAMETERS*/ BigDecimal limit,
/*IMPORTS*/ import org.apache.jdo.tck.pc.company.Project; +
import java.math.BigDecimal,
/*GROUP BY*/firstname, lastname HAVING
lastname.startsWith('emp'),
/*ORDER BY*/lastname ASCENDING,
/*FROM*/0,
/*TO*/ 3)
001 error: javax.jdo.JDODataStoreException: Error executing JDOQL query
SELECT DISTINCT THIS.FIRSTNAME AS firstName,THIS.LASTNAME AS
lastName,THIS.LASTNAME FROM datastoreidentity0.PERSONS THIS INNER JOIN
datastoreidentity0.PROJECT_MEMBER THIS_PROJECTS ON THIS_PROJECTS.MEMBER =
THIS.DATASTORE_IDENTITY INNER JOIN datastoreidentity0.PROJECTS UNBOUND_P ON
UNBOUND_P.DATASTORE_IDENTITY = THIS_PROJECTS.PROJID LEFT OUTER JOIN
datastoreidentity0.PROJECTS UNBOUND_P_BUDGET ON UNBOUND_P.DATASTORE_IDENTITY
= UNBOUND_P_BUDGET.DATASTORE_IDENTITY WHERE THIS.DISCRIMINATOR = ? AND
THIS.SALARY 1000 AND UNBOUND_P_BUDGET.BUDGET .2E4 GROUP BY
THIS.FIRSTNAME,THIS.LASTNAME HAVING LOCATE(?,THIS.LASTNAME) = 1 ORDER BY
THIS.LASTNAME : Column name 'LASTNAME' appears more than once in the result
of the query expression.
--
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-72) Test api.persistencemanager.OptimisticFailure hangs
[ http://issues.apache.org/jira/browse/JDO-72?page=all ]
Andy Jefferson resolved JDO-72:
---
Resolution: Fixed
Assign To: Andy Jefferson (was: Erik Bengtson)
Fixed in JPOX CVS - builds dated 29/12/2005 or later.
Now returns 3 nested exceptions, and the test passes :-)
Test api.persistencemanager.OptimisticFailure hangs
---
Key: JDO-72
URL: http://issues.apache.org/jira/browse/JDO-72
Project: JDO
Type: Bug
Components: tck20
Environment: JPOX, Derby
Reporter: Craig Russell
Assignee: Andy Jefferson
This test is designed to create conflicts in the database from two different
JDO transactions. The changes in the cache must not be visible in the
datastore or timeouts will occur. The exception here occurs when the second
optimistic JDO transaction attempts to read a row that has been changed in
the cache by the first optimistic JDO transaction.
private void runTestOptimistic(PersistenceManager pm1,
PersistenceManager pm2,
PersistenceManager pm3) {
if (!isOptimisticSupported()) {
if (debug)
logger.debug(OptimisticFailure tests not run; Optimistic not
supported);
return;
}
Transaction tx1 = pm1.currentTransaction();
Transaction tx2 = pm2.currentTransaction();
Transaction tx3 = pm3.currentTransaction();
try {
tx1.setOptimistic(true);
tx2.setOptimistic(true);
// create four instances to test
tx1.begin();
pm1.makePersistent(p1);
pm1.makePersistent(p2);
pm1.makePersistent(p3);
pm1.makePersistent(p4);
pm1.makePersistent(p5);
p1oid = pm1.getObjectId(p1);
p2oid = pm1.getObjectId(p2);
p3oid = pm1.getObjectId(p3);
p4oid = pm1.getObjectId(p4);
p5oid = pm1.getObjectId(p5);
tx1.commit();
// update/delete the instances in tx1
tx1.begin();
PCPoint p1tx1 = (PCPoint)pm1.getObjectById(p1oid, true);
PCPoint p2tx1 = (PCPoint)pm1.getObjectById(p2oid, true);
PCPoint p3tx1 = (PCPoint)pm1.getObjectById(p3oid, true);
PCPoint p4tx1 = (PCPoint)pm1.getObjectById(p4oid, true);
p1tx1.setX(101);
p2tx1.setX(201);
pm1.deletePersistent(p3tx1);
pm1.deletePersistent(p4tx1);
// update/delete the instances in tx2
tx2.begin();
*** PCPoint p1tx2 = (PCPoint)pm2.getObjectById(p1oid, true); *** this is
where the test hangs ***
PCPoint p2tx2 = (PCPoint)pm2.getObjectById(p2oid, true);
PCPoint p3tx2 = (PCPoint)pm2.getObjectById(p3oid, true);
PCPoint p4tx2 = (PCPoint)pm2.getObjectById(p4oid, true);
PCPoint p5tx2 = (PCPoint)pm2.getObjectById(p5oid, true);
p1tx2.setX(102);
// pm2.deletePersistent(p2tx2); // this should fail but succeeds
due to an RI bug
p3tx2.setX(202);
pm2.deletePersistent(p4tx2);
p5tx2.setX(502); // this change should not be committed
Set expectedFailedObjects = new HashSet();
expectedFailedObjects.add(p1tx2);
// expectedFailedObjects.add(p2tx2);
expectedFailedObjects.add(p3tx2);
expectedFailedObjects.add(p4tx2);
// commit tx1 (should succeed)
tx1.commit();
tx1 = null;
// commit tx2 (should fail)
try {
tx2.commit();
fail(ASSERTION_FAILED, concurrent commit not detected);
}
catch (JDOOptimisticVerificationException ex) {
// verify the correct information in the exception
RUN OptimisticFailure.test[INFO] tck - Exception during setUp or runtest:
javax.jdo.JDODataStoreException: Fetch request failed: SELECT
PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
[java] NestedThrowables:
[java] SQL Exception: A lock could not be obtained within the time
requestedjavax.jdo.JDODataStoreException: Fetch request failed: SELECT
PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
[java] at
org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:195)
[java] at
org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:1739)
[java] at org.jpox.store.StoreManager.fetch(StoreManager.java:665)
[java] at
org.jpox.state.StateManagerImpl.loadDFGFields(StateManagerImpl.java:1573)
[java] at
org.jpox.state.StateManagerImpl.loadDefaultFetchGroup(StateManagerImpl.java:1666)
[java] at
[jira] Reopened: (JDO-220) JPOX does not call jdoPostLoad() on queried instances or does not load fetch groups
[ http://issues.apache.org/jira/browse/JDO-220?page=all ] Andy Jefferson reopened JDO-220: Reopen issue since it failed to move to Resolved when asked to yet no longer shows the Resolve Issue option ... Apache JIRA problem by the look of it JPOX does not call jdoPostLoad() on queried instances or does not load fetch groups Key: JDO-220 URL: http://issues.apache.org/jira/browse/JDO-220 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Query test case GetFetchPlan fails throwing the exception below. The test case queries an instance of PCClass. PCClass has two persistent fields and two corresponding transient fields which are set by jdoPostLoad(). Furthermore, PCClass has two fetch groups. Each persistent field is contained in one of those fetch groups. The test case checks if the queried instance has the right values wrt transient fields. This check fails. junit.framework.AssertionFailedError: Assertion A14.6-21 (FetchPan) failed: Field PCClass.number1 is in the default fetch group and should have been loaded. The jdoPostLoad() callback has copied the field value to a transient field which has an unexpected value: 0 at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.query.api.GetFetchPlan.checkDefaultFetchGroup(GetFetchPlan.java:94) at org.apache.jdo.tck.query.api.GetFetchPlan.testPositive(GetFetchPlan.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-265) JPOX throws exception if default (empty) SELECT clause
[ http://issues.apache.org/jira/browse/JDO-265?page=all ] Andy Jefferson resolved JDO-265: Resolution: Duplicate Dup of JDO-248 JPOX throws exception if default (empty) SELECT clause -- Key: JDO-265 URL: http://issues.apache.org/jira/browse/JDO-265 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson testMap(org.apache.jdo.tck.query.result.ResultClassRequirements)javax.jdo.JDODataStoreException: Error executing JDOQL query SELECT FROM datastoreidentity0.PERSONS THIS WHERE THIS.DISCRIMINATOR = ? : Syntax error: Encountered FROM at line 1, column 9. ERROR 42X01: Syntax error: Encountered FROM at line 1, column 9. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190) at org.jpox.store.StatementText.prepareStatement(StatementText.java:199) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:680) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1153) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1031) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:968) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:948) at org.apache.jdo.tck.query.result.ResultClassRequirements.executeQuery(ResultClassRequirements.java:464) at org.apache.jdo.tck.query.result.ResultClassRequirements.testMap(ResultClassRequirements.java:424) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) . at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:749) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1153) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1031) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:968) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:948) at org.apache.jdo.tck.query.result.ResultClassRequirements.executeQuery(ResultClassRequirements.java:464) at org.apache.jdo.tck.query.result.ResultClassRequirements.testMap(ResultClassRequirements.java:424) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-244) JPOX generates illegal SQL for having clauses using COUNT.
[ http://issues.apache.org/jira/browse/JDO-244?page=comments#action_12361095 ] Andy Jefferson commented on JDO-244: Looked at the SQL being generated ? JPOX generates illegal SQL for having clauses using COUNT. -- Key: JDO-244 URL: http://issues.apache.org/jira/browse/JDO-244 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Attachments: JDO-244.patch JPOX generates illegal SQL for the query below. The having clause specifies an aggregate COUNT. 14:22:50,906 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT department, SUM(salary) FROM org.apache.jdo.tck.pc.company.Employee GROUP BY department HAVING COUNT(department.employees) 0 14:22:51,031 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: javax.jdo.JDODataStoreException: Error executing JDOQL query SELECT THIS.DEPARTMENT,SUM(THIS.SALARY) FROM applicationidentity0.PERSONS THIS LEFT OUTER JOIN applicationidentity0.DEPARTMENTS THIS_DEPARTMENT_EMPLOYEES ON THIS.DEPARTMENT = THIS_DEPARTMENT_EMPLOYEES.ID WHERE THIS.DISCRIMINATOR = ? OR THIS.DISCRIMINATOR = ? OR THIS.DISCRIMINATOR = ? GROUP BY THIS.DEPARTMENT HAVING COUNT() 0 : Syntax error: Encountered ) at line 1, column 324. ERROR 42X01: Syntax error: Encountered ) at line 1, column 324. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190) at org.jpox.store.StatementText.prepareStatement(StatementText.java:199) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:678) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:946) at org.apache.jdo.tck.query.result.Having.testPositive(Having.java:110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) . at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:747) at org.jpox.store.query.Query.executeWithMap(Query.java:966) at org.jpox.store.query.Query.executeWithArray(Query.java:939) at org.jpox.store.query.Query.execute(Query.java:862) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) at
[jira] Commented: (JDO-72) Test api.persistencemanager.OptimisticFailure hangs
[ http://issues.apache.org/jira/browse/JDO-72?page=comments#action_12361030
]
Andy Jefferson commented on JDO-72:
---
Current support is for date-time, and version-number.
Test api.persistencemanager.OptimisticFailure hangs
---
Key: JDO-72
URL: http://issues.apache.org/jira/browse/JDO-72
Project: JDO
Type: Bug
Components: tck20
Environment: JPOX, Derby
Reporter: Craig Russell
Assignee: Erik Bengtson
This test is designed to create conflicts in the database from two different
JDO transactions. The changes in the cache must not be visible in the
datastore or timeouts will occur. The exception here occurs when the second
optimistic JDO transaction attempts to read a row that has been changed in
the cache by the first optimistic JDO transaction.
private void runTestOptimistic(PersistenceManager pm1,
PersistenceManager pm2,
PersistenceManager pm3) {
if (!isOptimisticSupported()) {
if (debug)
logger.debug(OptimisticFailure tests not run; Optimistic not
supported);
return;
}
Transaction tx1 = pm1.currentTransaction();
Transaction tx2 = pm2.currentTransaction();
Transaction tx3 = pm3.currentTransaction();
try {
tx1.setOptimistic(true);
tx2.setOptimistic(true);
// create four instances to test
tx1.begin();
pm1.makePersistent(p1);
pm1.makePersistent(p2);
pm1.makePersistent(p3);
pm1.makePersistent(p4);
pm1.makePersistent(p5);
p1oid = pm1.getObjectId(p1);
p2oid = pm1.getObjectId(p2);
p3oid = pm1.getObjectId(p3);
p4oid = pm1.getObjectId(p4);
p5oid = pm1.getObjectId(p5);
tx1.commit();
// update/delete the instances in tx1
tx1.begin();
PCPoint p1tx1 = (PCPoint)pm1.getObjectById(p1oid, true);
PCPoint p2tx1 = (PCPoint)pm1.getObjectById(p2oid, true);
PCPoint p3tx1 = (PCPoint)pm1.getObjectById(p3oid, true);
PCPoint p4tx1 = (PCPoint)pm1.getObjectById(p4oid, true);
p1tx1.setX(101);
p2tx1.setX(201);
pm1.deletePersistent(p3tx1);
pm1.deletePersistent(p4tx1);
// update/delete the instances in tx2
tx2.begin();
*** PCPoint p1tx2 = (PCPoint)pm2.getObjectById(p1oid, true); *** this is
where the test hangs ***
PCPoint p2tx2 = (PCPoint)pm2.getObjectById(p2oid, true);
PCPoint p3tx2 = (PCPoint)pm2.getObjectById(p3oid, true);
PCPoint p4tx2 = (PCPoint)pm2.getObjectById(p4oid, true);
PCPoint p5tx2 = (PCPoint)pm2.getObjectById(p5oid, true);
p1tx2.setX(102);
// pm2.deletePersistent(p2tx2); // this should fail but succeeds
due to an RI bug
p3tx2.setX(202);
pm2.deletePersistent(p4tx2);
p5tx2.setX(502); // this change should not be committed
Set expectedFailedObjects = new HashSet();
expectedFailedObjects.add(p1tx2);
// expectedFailedObjects.add(p2tx2);
expectedFailedObjects.add(p3tx2);
expectedFailedObjects.add(p4tx2);
// commit tx1 (should succeed)
tx1.commit();
tx1 = null;
// commit tx2 (should fail)
try {
tx2.commit();
fail(ASSERTION_FAILED, concurrent commit not detected);
}
catch (JDOOptimisticVerificationException ex) {
// verify the correct information in the exception
RUN OptimisticFailure.test[INFO] tck - Exception during setUp or runtest:
javax.jdo.JDODataStoreException: Fetch request failed: SELECT
PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
[java] NestedThrowables:
[java] SQL Exception: A lock could not be obtained within the time
requestedjavax.jdo.JDODataStoreException: Fetch request failed: SELECT
PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
[java] at
org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:195)
[java] at
org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:1739)
[java] at org.jpox.store.StoreManager.fetch(StoreManager.java:665)
[java] at
org.jpox.state.StateManagerImpl.loadDFGFields(StateManagerImpl.java:1573)
[java] at
org.jpox.state.StateManagerImpl.loadDefaultFetchGroup(StateManagerImpl.java:1666)
[java] at
org.jpox.state.StateManagerImpl.validate(StateManagerImpl.java:3456)
[java] at
[jira] Commented: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12361036 ] Andy Jefferson commented on JDO-194: Thanks for the stack trace Michael. Seems that some Windows JREs sometimes throw a NoClassDefFoundError and Unix JREs dont - nice consistent platform-independent approach. JPOX CVS (builds from 22/12/2005 onwards) now checks for this and acts accordingly. Give it a try since I can't :-) JPOX does not support implicit variables. - Key: JDO-194 URL: http://issues.apache.org/jira/browse/JDO-194 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson JPOX throws an exception executing queries having implicit parameters (see below). The bug may be reproduced executing test case org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE team.contains(employee) employee.firstname == 'emp1First' org.jpox.store.exceptions.NoSuchPersistentFieldException: Field employee does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent at org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) at org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) at org.jpox.store.query.Query.executeWithMap(Query.java:907) at org.jpox.store.query.Query.executeWithArray(Query.java:887) at org.jpox.store.query.Query.execute(Query.java:819) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:706) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:625) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:601) at org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields.testPositive(VariablesAndFields.java:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] Assigned: (JDO-263) TestArrayCollections: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 is declared as a reference type (interface/Object) but no implementation class
[ http://issues.apache.org/jira/browse/JDO-263?page=all ] Andy Jefferson reassigned JDO-263: -- Assign To: Michelle Caisse (was: Andy Jefferson) Changed JPOX to support this element-type attribute. You now have test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)java.lang.NullPointerException [java] at java.lang.System.arraycopy(Native Method) [java] at java.util.Vector.copyInto(Vector.java:166) [java] at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.setValues(TestArrayCollections.java:134) [java] at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:96) [java] at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) TestArrayCollections: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 is declared as a reference type (interface/Object) but no implementation classes of java.lang.Object have been found! -- Key: JDO-263 URL: http://issues.apache.org/jira/browse/JDO-263 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Michelle Caisse test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)javax.jdo.JDOUserException: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 is declared as a reference type (interface/Object) but no implementation classes of java.lang.Object have been found! at org.jpox.metadata.MetaDataUtils.getImplementationNamesForReferenceField(MetaDataUtils.java:594) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForReferenceField(ColumnCreator.java:184) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:296) at org.jpox.store.rdbms.table.ColumnCreator.createColumns(ColumnCreator.java:95) at org.jpox.store.rdbms.table.ArrayTable.initialize(ArrayTable.java:83) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2404) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2033) at org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:1893) at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:479) at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:493) at org.jpox.store.rdbms.RDBMSManager.getDatastoreClass(RDBMSManager.java:766) at org.jpox.state.StateManagerImpl.populateStrategyFields(StateManagerImpl.java:781) at org.jpox.state.StateManagerImpl.init(StateManagerImpl.java:584) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1076) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1131) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:93) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12360941 ] Andy Jefferson commented on JDO-194: And I have a clean checkout of about 30 mins ago and still get no errors whatsoever on those tests. Perhaps something in your setup ? I use Linux and Maven 1.0.2. You use Windows don't you Michael ? The issue is more than likely some windows case-sensitivity or file separator issue. JPOX does not support implicit variables. - Key: JDO-194 URL: http://issues.apache.org/jira/browse/JDO-194 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson JPOX throws an exception executing queries having implicit parameters (see below). The bug may be reproduced executing test case org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE team.contains(employee) employee.firstname == 'emp1First' org.jpox.store.exceptions.NoSuchPersistentFieldException: Field employee does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent at org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) at org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) at org.jpox.store.query.Query.executeWithMap(Query.java:907) at org.jpox.store.query.Query.executeWithArray(Query.java:887) at org.jpox.store.query.Query.execute(Query.java:819) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:706) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:625) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:601) at org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields.testPositive(VariablesAndFields.java:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] Commented: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12360959 ] Andy Jefferson commented on JDO-194: JPOX would have to check for whether something is a class or not before falling back to implicit variable. As for which variable employee is the issue I've no idea ... but then I don't see the issue so can't debug it. The stack trace line numbers provided by Michael above don't correspond to what I have in JPOX CVS either. Provide a valid stack trace using the most recent JPOX build, and just the part like the following at org.jpox.util.Imports.resolveClassDeclaration(Imports.java:152) at org.jpox.store.query.Query.resolveClassDeclaration(Query.java:844) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1993) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1650) Without valid line numbers I can't do a thing. JPOX does not support implicit variables. - Key: JDO-194 URL: http://issues.apache.org/jira/browse/JDO-194 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson JPOX throws an exception executing queries having implicit parameters (see below). The bug may be reproduced executing test case org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE team.contains(employee) employee.firstname == 'emp1First' org.jpox.store.exceptions.NoSuchPersistentFieldException: Field employee does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent at org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) at org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) at org.jpox.store.query.Query.executeWithMap(Query.java:907) at
[jira] Resolved: (JDO-255) Inheritance mapping 1 fails for application identity.
[ http://issues.apache.org/jira/browse/JDO-255?page=all ] Andy Jefferson resolved JDO-255: Resolution: Duplicate Duplicate of JDO-255. Please refer to http://www.jpox.org/servlet/jira/browse/CORE-2610 for details Inheritance mapping 1 fails for application identity. - Key: JDO-255 URL: http://issues.apache.org/jira/browse/JDO-255 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test data has been changed for all inheritance mappings from companyNoRelationships to companyAllRelationships. Since this change, inheritance mapping 1 for application identity fails throwing a ClassCastException: 1) test(org.apache.jdo.tck.mapping.CompletenessTest)java.lang.ClassCastException at org.apache.jdo.tck.pc.company.Employee.jdoReplaceField(Employee.java) at org.apache.jdo.tck.pc.company.PartTimeEmployee.jdoReplaceField(PartTimeEmployee.java) at org.apache.jdo.tck.pc.company.Person.jdoReplaceFields(Person.java) at org.jpox.state.StateManagerImpl.replaceFields(StateManagerImpl.java:2850) at org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:187) at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2094) at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2087) at org.jpox.store.StoreManager.fetch(StoreManager.java:754) at org.jpox.state.StateManagerImpl.loadNonDFGFields(StateManagerImpl.java:1576) at org.jpox.state.StateManagerImpl.isLoaded(StateManagerImpl.java:1753) at org.apache.jdo.tck.pc.company.Employee.jdoGetdentalInsurance(Employee.java) at org.apache.jdo.tck.pc.company.Employee.getDentalInsurance(Employee.java:194) at org.apache.jdo.tck.pc.company.Employee.deepCompareFields(Employee.java:447) at org.apache.jdo.tck.pc.company.PartTimeEmployee.deepCompareFields(PartTimeEmployee.java:119) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.mapping.CompletenessTest.test(CompletenessTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-256) Inheritance mapping 1 fails for datastore identity.
[ http://issues.apache.org/jira/browse/JDO-256?page=comments#action_12360653 ] Andy Jefferson commented on JDO-256: Please refer to http://www.jpox.org/servlet/jira/browse/CORE-2610 for details. No point us duplicating details across 2 JIRA systems. Inheritance mapping 1 fails for datastore identity. --- Key: JDO-256 URL: http://issues.apache.org/jira/browse/JDO-256 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test data has been changed for all inheritance mappings from companyNoRelationships to companyAllRelationships. Since this change, inheritance mapping 1 for datastore identity fails throwing a JDOObjectNotFoundException: 1) test(org.apache.jdo.tck.mapping.CompletenessTest)javax.jdo.JDOObjectNotFoundException: No such database row FailedObject:9[OID]org.apache.jdo.tck.pc.company.DentalInsurance at org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:185) at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2094) at org.jpox.store.StoreManager.fetch(StoreManager.java:754) at org.jpox.state.StateManagerImpl.loadDFGFields(StateManagerImpl.java:1549) at org.jpox.state.StateManagerImpl.isLoaded(StateManagerImpl.java:1749) at org.apache.jdo.tck.pc.company.Insurance.jdoGetinsid(Insurance.java) at org.apache.jdo.tck.pc.company.Insurance.getInsid(Insurance.java:67) at org.apache.jdo.tck.pc.company.Insurance.deepCompareFields(Insurance.java:144) at org.apache.jdo.tck.pc.company.DentalInsurance.deepCompareFields(DentalInsurance.java:112) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Employee.deepCompareFields(Employee.java:447) at org.apache.jdo.tck.pc.company.PartTimeEmployee.deepCompareFields(PartTimeEmployee.java:119) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.mapping.CompletenessTest.test(CompletenessTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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] Assigned: (JDO-256) Inheritance mapping 1 fails for datastore identity.
[ http://issues.apache.org/jira/browse/JDO-256?page=all ] Andy Jefferson reassigned JDO-256: -- Assign To: Andy Jefferson (was: Erik Bengtson) Inheritance mapping 1 fails for datastore identity. --- Key: JDO-256 URL: http://issues.apache.org/jira/browse/JDO-256 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson Test data has been changed for all inheritance mappings from companyNoRelationships to companyAllRelationships. Since this change, inheritance mapping 1 for datastore identity fails throwing a JDOObjectNotFoundException: 1) test(org.apache.jdo.tck.mapping.CompletenessTest)javax.jdo.JDOObjectNotFoundException: No such database row FailedObject:9[OID]org.apache.jdo.tck.pc.company.DentalInsurance at org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:185) at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2094) at org.jpox.store.StoreManager.fetch(StoreManager.java:754) at org.jpox.state.StateManagerImpl.loadDFGFields(StateManagerImpl.java:1549) at org.jpox.state.StateManagerImpl.isLoaded(StateManagerImpl.java:1749) at org.apache.jdo.tck.pc.company.Insurance.jdoGetinsid(Insurance.java) at org.apache.jdo.tck.pc.company.Insurance.getInsid(Insurance.java:67) at org.apache.jdo.tck.pc.company.Insurance.deepCompareFields(Insurance.java:144) at org.apache.jdo.tck.pc.company.DentalInsurance.deepCompareFields(DentalInsurance.java:112) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Employee.deepCompareFields(Employee.java:447) at org.apache.jdo.tck.pc.company.PartTimeEmployee.deepCompareFields(PartTimeEmployee.java:119) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.mapping.CompletenessTest.test(CompletenessTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-255) Inheritance mapping 1 fails for application identity.
[ http://issues.apache.org/jira/browse/JDO-255?page=comments#action_12360654 ] Andy Jefferson commented on JDO-255: That should have read, duplicate of JDO-256 :-) Inheritance mapping 1 fails for application identity. - Key: JDO-255 URL: http://issues.apache.org/jira/browse/JDO-255 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test data has been changed for all inheritance mappings from companyNoRelationships to companyAllRelationships. Since this change, inheritance mapping 1 for application identity fails throwing a ClassCastException: 1) test(org.apache.jdo.tck.mapping.CompletenessTest)java.lang.ClassCastException at org.apache.jdo.tck.pc.company.Employee.jdoReplaceField(Employee.java) at org.apache.jdo.tck.pc.company.PartTimeEmployee.jdoReplaceField(PartTimeEmployee.java) at org.apache.jdo.tck.pc.company.Person.jdoReplaceFields(Person.java) at org.jpox.state.StateManagerImpl.replaceFields(StateManagerImpl.java:2850) at org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:187) at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2094) at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2087) at org.jpox.store.StoreManager.fetch(StoreManager.java:754) at org.jpox.state.StateManagerImpl.loadNonDFGFields(StateManagerImpl.java:1576) at org.jpox.state.StateManagerImpl.isLoaded(StateManagerImpl.java:1753) at org.apache.jdo.tck.pc.company.Employee.jdoGetdentalInsurance(Employee.java) at org.apache.jdo.tck.pc.company.Employee.getDentalInsurance(Employee.java:194) at org.apache.jdo.tck.pc.company.Employee.deepCompareFields(Employee.java:447) at org.apache.jdo.tck.pc.company.PartTimeEmployee.deepCompareFields(PartTimeEmployee.java:119) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.mapping.CompletenessTest.test(CompletenessTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-241) JPOX returns wrong query result for non-extent queries.
[
http://issues.apache.org/jira/browse/JDO-241?page=comments#action_12360498 ]
Andy Jefferson commented on JDO-241:
If you look at the test you find that the candidate collection passed in is
of transient instances which hence have no identity (or at least
JDOHelper.getObjectId() returns null). You are expecting the JDO implementation
to find these instances without allowing it to know their identities ? H
To quote the spec [14.6] :
spec
For portability, the elements in the collection must be persistent instances
associated with the same
PersistenceManager as the Query instance. An implementation might support
transient instances in the collection.
/spec
I notice that the second sentence here has a word might. Hence the test
cannot impose the restriction since its an optional feature.
JPOX returns wrong query result for non-extent queries.
---
Key: JDO-241
URL: http://issues.apache.org/jira/browse/JDO-241
Project: JDO
Type: Bug
Components: tck20
Reporter: Michael Watzek
Assignee: Erik Bengtson
Test case DistinctCandidateInstances fails because JPOX returns an empty
collection for the query below. The query uses a candidate collection.
14:22:46,781 (main) DEBUG [org.apache.jdo.tck] - Executing JDO query: SELECT
FROM org.apache.jdo.tck.pc.company.Person
14:22:46,796 (main) DEBUG [org.apache.jdo.tck] - Query result: []
14:22:46,812 (main) DEBUG [org.apache.jdo.tck] - Wrong query result:
expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
{work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
{work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
{work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
{work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
{work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
{work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
{work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
{work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
{work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
{work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
got: []
14:22:46,812 (main) INFO [org.apache.jdo.tck] - Exception during setUp or
runtest:
junit.framework.AssertionFailedError: Assertion A14.6.9-2
(DistintCandidateInstances) failed:
Wrong query result:
expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
{work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
{work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
{work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
{work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
{work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
{work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
{work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
{work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
{work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
{work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
got: []
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546)
at org.apache.jdo.tck.query.QueryTest.queryFailed(QueryTest.java:500)
at
org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder(QueryTest.java:485)
[jira] Commented: (JDO-220) JPOX does not call jdoPostLoad() on queried instances or does not load fetch groups
[ http://issues.apache.org/jira/browse/JDO-220?page=comments#action_12360512 ] Andy Jefferson commented on JDO-220: The second of the fields (number2) is checked that it is not loaded. So what about the case where the object has been pulled from the cache ? The field number2 will still be loaded and consequently that part of the test will fail. JPOX does not call jdoPostLoad() on queried instances or does not load fetch groups Key: JDO-220 URL: http://issues.apache.org/jira/browse/JDO-220 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Query test case GetFetchPlan fails throwing the exception below. The test case queries an instance of PCClass. PCClass has two persistent fields and two corresponding transient fields which are set by jdoPostLoad(). Furthermore, PCClass has two fetch groups. Each persistent field is contained in one of those fetch groups. The test case checks if the queried instance has the right values wrt transient fields. This check fails. junit.framework.AssertionFailedError: Assertion A14.6-21 (FetchPan) failed: Field PCClass.number1 is in the default fetch group and should have been loaded. The jdoPostLoad() callback has copied the field value to a transient field which has an unexpected value: 0 at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.query.api.GetFetchPlan.checkDefaultFetchGroup(GetFetchPlan.java:94) at org.apache.jdo.tck.query.api.GetFetchPlan.testPositive(GetFetchPlan.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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] Assigned: (JDO-261) TestHashSetCollections, TestSetCollections : schema incorrect
[ http://issues.apache.org/jira/browse/JDO-261?page=all ] Andy Jefferson reassigned JDO-261: -- Assign To: Michelle Caisse (was: Andy Jefferson) Well if you look at the message received Add request failed : INSERT INTO datastoreidentity0.HASHSET_OF_OBJECT2 (IDENTIFIER,COLLVAL,ADPT_PK_IDX) VALUES (?,?,?) you have a field that has a serialised element. You have an ORM definition of field name=HashSetOfObject2 table=HASHSET_OF_OBJECT2 join column=IDENTIFIER/ element column=COLLVAL/ /field So in the join table we have a FK back to the owner, a value column, and we need to impose a PK (since I have no spec that defines how to specify that no PK is required). I don't see any primary-key specification, so how does JPOX know what is the PK of this join table ? TestHashSetCollections, TestSetCollections : schema incorrect - Key: JDO-261 URL: http://issues.apache.org/jira/browse/JDO-261 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assignee: Michelle Caisse HashSetCollections/SetCollections are mapped incorrectly. They should have a primary-key specified in the metadata to tell the JDO implementation which columns to use for PK. Without this the JDO implementation can do whatever it likes wrt defining a PK. This includes adding its own adapter columns. -- 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-243) JPOX must throw JDOUserException for group by queries which select non-grouped fields.
[ http://issues.apache.org/jira/browse/JDO-243?page=comments#action_12360413 ] Andy Jefferson commented on JDO-243: OK, so lets take this one step further then. I look at SingleStringQuery test. It requires a query with a result clause, an ordering clause and a grouping clause. The grouping provided is consistent with the result clause, but the grouping clause doesnt include the field that is required for ordering. When we convert this into a SQL SELECT, using the policy of never adding anything that the user doesnt explicitly provide we would end up with a statement SELECT a, b FROM t GROUP BY a, b ORDER BY c and Derby will promptly throw an error because c is not in the SELECT clause. The JDO impl could add the ordering column(s) to the SELECT clause, but then Derby will promptly throw an error because c is not in the GROUP BY clause. For a SELECT list with a GROUP BY, the list may only contain grouping columns and valid aggregate expressions So what do we do in this situation? The implementation is presumably allowed to add the ordering column(s) to the select, but isn't permitted to add it to the grouping ? JPOX must throw JDOUserException for group by queries which select non-grouped fields. -- Key: JDO-243 URL: http://issues.apache.org/jira/browse/JDO-243 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test case Grouping fails for the query below. The query is expected to throw a JDOUserException because field salary is contained in the result clause and not contained in the group by clause. 14:22:49,328 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT department, salary FROM org.apache.jdo.tck.pc.company.Employee GROUP BY department 14:22:49,328 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw JDOUserException: null 14:22:49,328 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A14.6.10-1 (Grouping) failed: Query compilation must throw JDOUserException: null at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878) at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) at org.apache.jdo.tck.query.result.Grouping.testNegative(Grouping.java:122) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-260) TestHashMapStringKeyCollections.test : schema incorrect
TestHashMapStringKeyCollections.test : schema incorrect --- Key: JDO-260 URL: http://issues.apache.org/jira/browse/JDO-260 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assigned to: Michelle Caisse Test TestHashMapStringKeyCollections (datastore-identity) fails with ERROR 42X14: 'HASH_MAP_OF_STRING_SIMPLE_INTERFACE90' is not a column in table or VTI 'DATASTOREIDENTITY0.HASHMAPSTRINGKEY_COLLECTIONS'. The schema is inconsistent with the MetaData. If you compare it with the MapStringKeyCollections case you find that this same field is mapped differently in the metadata. -- 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-261) TestHashSetCollections, TestSetCollections : schema incorrect
TestHashSetCollections, TestSetCollections : schema incorrect - Key: JDO-261 URL: http://issues.apache.org/jira/browse/JDO-261 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assigned to: Michelle Caisse HashSetCollections/SetCollections are mapped incorrectly. They should have a primary-key specified in the metadata to tell the JDO implementation which columns to use for PK. Without this the JDO implementation can do whatever it likes wrt defining a PK. This includes adding its own adapter columns. -- 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-256) Inheritance mapping 1 fails for datastore identity.
[ http://issues.apache.org/jira/browse/JDO-256?page=comments#action_12360294 ] Andy Jefferson commented on JDO-256: Any chance of a clue as to what data has changed ? Something to do with medical and dental insurance ? Wading through this object model and trying to debug some clue out of it is too time consuming Inheritance mapping 1 fails for datastore identity. --- Key: JDO-256 URL: http://issues.apache.org/jira/browse/JDO-256 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test data has been changed for all inheritance mappings from companyNoRelationships to companyAllRelationships. Since this change, inheritance mapping 1 for datastore identity fails throwing a JDOObjectNotFoundException: 1) test(org.apache.jdo.tck.mapping.CompletenessTest)javax.jdo.JDOObjectNotFoundException: No such database row FailedObject:9[OID]org.apache.jdo.tck.pc.company.DentalInsurance at org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:185) at org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:2094) at org.jpox.store.StoreManager.fetch(StoreManager.java:754) at org.jpox.state.StateManagerImpl.loadDFGFields(StateManagerImpl.java:1549) at org.jpox.state.StateManagerImpl.isLoaded(StateManagerImpl.java:1749) at org.apache.jdo.tck.pc.company.Insurance.jdoGetinsid(Insurance.java) at org.apache.jdo.tck.pc.company.Insurance.getInsid(Insurance.java:67) at org.apache.jdo.tck.pc.company.Insurance.deepCompareFields(Insurance.java:144) at org.apache.jdo.tck.pc.company.DentalInsurance.deepCompareFields(DentalInsurance.java:112) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Employee.deepCompareFields(Employee.java:447) at org.apache.jdo.tck.pc.company.PartTimeEmployee.deepCompareFields(PartTimeEmployee.java:119) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.pc.company.Department.deepCompareFields(Department.java:245) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:387) at org.apache.jdo.tck.util.EqualityHelper.deepEquals(EqualityHelper.java:483) at org.apache.jdo.tck.pc.company.Company.deepCompareFields(Company.java:220) at org.apache.jdo.tck.mapping.CompletenessTest.test(CompletenessTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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] Assigned: (JDO-239) JPOX throws NPE when result class is specified with no result clause for deletion by query using single string query.
[ http://issues.apache.org/jira/browse/JDO-239?page=all ] Andy Jefferson reassigned JDO-239: -- Assign To: Andy Jefferson (was: Erik Bengtson) JPOX throws NPE when result class is specified with no result clause for deletion by query using single string query. - Key: JDO-239 URL: http://issues.apache.org/jira/browse/JDO-239 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson The test case DeleteQueryElements fails throwing a NPE for the query below. The test case is expected to thow a JDOUserException. The same test case succeeds when an API query is used. 14:22:25,250 (main) DEBUG [org.apache.jdo.tck] - Deleting persistent by single string query: SELECT INTO org.apache.jdo.tck.query.result.classes.FullName FROM org.apache.jdo.tck.pc.company.Person 14:22:25,250 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: java.lang.NullPointerException at org.jpox.store.query.ResultClassROF.init(ResultClassROF.java:99) at org.jpox.store.rdbms.extent.ClassTableExtent.newResultObjectFactory(ClassTableExtent.java:374) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:642) at org.jpox.store.query.JDOQLQuery.performDeletePersistentAll(JDOQLQuery.java:764) at org.jpox.store.query.Query.deletePersistentAll(Query.java:1131) at org.jpox.store.query.Query.deletePersistentAll(Query.java:1094) at org.jpox.store.query.Query.deletePersistentAll(Query.java:1068) at org.apache.jdo.tck.query.QueryTest.delete(QueryTest.java:1322) at org.apache.jdo.tck.query.QueryTest.delete(QueryTest.java:1286) at org.apache.jdo.tck.query.QueryTest.deletePersistentAllBySingleStringQuery(QueryTest.java:1259) at org.apache.jdo.tck.query.delete.DeleteQueryElements.testNegative(DeleteQueryElements.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-239) JPOX throws NPE when result class is specified with no result clause for deletion by query using single string query.
[ http://issues.apache.org/jira/browse/JDO-239?page=all ] Andy Jefferson resolved JDO-239: Resolution: Fixed Fixed in JPOX CVS. Builds from 14/12/2005 will have this. JPOX throws NPE when result class is specified with no result clause for deletion by query using single string query. - Key: JDO-239 URL: http://issues.apache.org/jira/browse/JDO-239 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson The test case DeleteQueryElements fails throwing a NPE for the query below. The test case is expected to thow a JDOUserException. The same test case succeeds when an API query is used. 14:22:25,250 (main) DEBUG [org.apache.jdo.tck] - Deleting persistent by single string query: SELECT INTO org.apache.jdo.tck.query.result.classes.FullName FROM org.apache.jdo.tck.pc.company.Person 14:22:25,250 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: java.lang.NullPointerException at org.jpox.store.query.ResultClassROF.init(ResultClassROF.java:99) at org.jpox.store.rdbms.extent.ClassTableExtent.newResultObjectFactory(ClassTableExtent.java:374) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:642) at org.jpox.store.query.JDOQLQuery.performDeletePersistentAll(JDOQLQuery.java:764) at org.jpox.store.query.Query.deletePersistentAll(Query.java:1131) at org.jpox.store.query.Query.deletePersistentAll(Query.java:1094) at org.jpox.store.query.Query.deletePersistentAll(Query.java:1068) at org.apache.jdo.tck.query.QueryTest.delete(QueryTest.java:1322) at org.apache.jdo.tck.query.QueryTest.delete(QueryTest.java:1286) at org.apache.jdo.tck.query.QueryTest.deletePersistentAllBySingleStringQuery(QueryTest.java:1259) at org.apache.jdo.tck.query.delete.DeleteQueryElements.testNegative(DeleteQueryElements.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-243) JPOX must throw JDOUserException for group by queries which select non-grouped fields.
[ http://issues.apache.org/jira/browse/JDO-243?page=comments#action_12360312 ] Andy Jefferson commented on JDO-243: Why ? Is it not allowed for the JDO implementation to interpret that fields in the result should be automatically added to the grouping clause ? All fields in the result have to be in the grouping if they are in the result, so its hardly rocket science for a JDO impl to add them itself. JPOX must throw JDOUserException for group by queries which select non-grouped fields. -- Key: JDO-243 URL: http://issues.apache.org/jira/browse/JDO-243 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test case Grouping fails for the query below. The query is expected to throw a JDOUserException because field salary is contained in the result clause and not contained in the group by clause. 14:22:49,328 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT department, salary FROM org.apache.jdo.tck.pc.company.Employee GROUP BY department 14:22:49,328 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw JDOUserException: null 14:22:49,328 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A14.6.10-1 (Grouping) failed: Query compilation must throw JDOUserException: null at junit.framework.Assert.fail(Assert.java:47) at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915) at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878) at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) at org.apache.jdo.tck.query.result.Grouping.testNegative(Grouping.java:122) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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] Assigned: (JDO-227) ClassCastExcption on reading JDO metadata in TestMapStringValueCollections
[ http://issues.apache.org/jira/browse/JDO-227?page=all ] Andy Jefferson reassigned JDO-227: -- Assign To: Michelle Caisse (was: Andy Jefferson) Hi Michelle, I too was confused by the error message :-), until I looked in the JPOX log. The ORM file has errors. Look at line 59. You have a block of join out of place. A cut and paste issue I think - missing a field line at the start of the block. You have a field MapOfObject_String4 and then nothing til MapOfObject_String8, so comparing it with the other tests it should have a field line for MapOfObject_String6. I had a look at the rest of the file and I think thats the only error. ClassCastExcption on reading JDO metadata in TestMapStringValueCollections -- Key: JDO-227 URL: http://issues.apache.org/jira/browse/JDO-227 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Michelle Caisse This is strange because there is no error during enhancement. [java] 1) test(org.apache.jdo.tck.models.fieldtypes.TestMapStringValueCollections)javax.jdo.JDOException: Cannot read the JDO Meta-Data file input stream java.lang.ClassCastException [java] at org.jpox.metadata.MetaDataParser.parseMetaDataStream(MetaDataParser.java:174) [java] at org.jpox.metadata.MetaDataParser.parseMetaData(MetaDataParser.java:107) [java] at org.jpox.metadata.MetaDataManager.parseFile(MetaDataManager.java:711) [java] at org.jpox.metadata.MetaDataManager.loadMetaDataForClass(MetaDataManager.java:1371) [java] at org.jpox.metadata.MetaDataManager.addORMDataToClass(MetaDataManager.java:894) [java] at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:432) [java] at org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:853) [java] at org.jpox.metadata.MetaDataManager.loadMetaDataForClass(MetaDataManager.java:1377) [java] at org.jpox.metadata.MetaDataManager.getFileMetaDataForClass(MetaDataManager.java:529) [java] at org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:467) [java] at org.jpox.metadata.MetaDataManager.getClassMetaData(MetaDataManager.java:432) [java] at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:347) [java] at org.jpox.AbstractPersistenceManager.hasMetaDataForPersistenceCapableClass(AbstractPersistenceManager.java:3754) [java] at org.jpox.AbstractPersistenceManager.assertPersistenceCapable(AbstractPersistenceManager.java:3802) [java] at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:983) [java] at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1099) [java] at org.apache.jdo.tck.models.fieldtypes.TestMapStringValueCollections.runTest(TestMapStringValueCollections.java:105) [java] at org.apache.jdo.tck.models.fieldtypes.TestMapStringValueCollections.test(TestMapStringValueCollections.java:76) [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:120) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) [java] NestedThrowablesStackTrace: [java] java.lang.ClassCastException [java] at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:658) [java] at org.apache.crimson.parser.Parser2.parse(Parser2.java:333) [java] at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) [java] at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) [java] at javax.xml.parsers.SAXParser.parse(SAXParser.java:143) [java] at org.jpox.metadata.MetaDataParser.parseMetaDataStream(MetaDataParser.java:162) [java] at org.jpox.metadata.MetaDataParser.parseMetaData(MetaDataParser.java:107) [java] at org.jpox.metadata.MetaDataManager.parseFile(MetaDataManager.java:711) [java] at org.jpox.metadata.MetaDataManager.loadMetaDataForClass(MetaDataManager.java:1371) [java] at org.jpox.metadata.MetaDataManager.addORMDataToClass(MetaDataManager.java:894) [java] at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:432) [java] at org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:853) [java] at org.jpox.metadata.MetaDataManager.loadMetaDataForClass(MetaDataManager.java:1377) [java] at
[jira] Created: (JDO-226) DistintCandidateInstances.testCollectionQueries typo
DistintCandidateInstances.testCollectionQueries typo Key: JDO-226 URL: http://issues.apache.org/jira/browse/JDO-226 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assigned to: Michael Watzek Priority: Minor The TCK test DistintCandidateInstances (apart from being spelt incorrectly ... since Distinct has a c in it) has a typo in the query. It is using SELECT DISTNICT FROM + Person.class.getName() JPOX fails to detect DISTNICT as a keyword :-) -- 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-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=all ] Andy Jefferson resolved JDO-194: Resolution: Fixed This test passes and has for a week at least JPOX does not support implicit variables. - Key: JDO-194 URL: http://issues.apache.org/jira/browse/JDO-194 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Michael Watzek JPOX throws an exception executing queries having implicit parameters (see below). The bug may be reproduced executing test case org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE team.contains(employee) employee.firstname == 'emp1First' org.jpox.store.exceptions.NoSuchPersistentFieldException: Field employee does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent at org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) at org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) at org.jpox.store.query.Query.executeWithMap(Query.java:907) at org.jpox.store.query.Query.executeWithArray(Query.java:887) at org.jpox.store.query.Query.execute(Query.java:819) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:706) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:625) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:601) at org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields.testPositive(VariablesAndFields.java:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
[jira] Commented: (JDO-177) JPOX ignores JDOHelper.getObjectId in queries.
[ http://issues.apache.org/jira/browse/JDO-177?page=comments#action_12358491 ] Andy Jefferson commented on JDO-177: To be explicit, this only relates to queries where JDOHelper.getObjectId(this) is in the result clause. When it is in the filter clause all works fine. JPOX ignores JDOHelper.getObjectId in queries. -- Key: JDO-177 URL: http://issues.apache.org/jira/browse/JDO-177 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson JPOX ignores JDOHelper.getObjectId in queries. This bug may be reproduced applying patch JDO-159. The following query returns instances of FullTimeEmployee instead of objectid instances: SELECT JDOHelper.getObjectId(this) FROM org.apache.jdo.tck.pc.company.Person -- 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] Assigned: (JDO-177) JPOX ignores JDOHelper.getObjectId in queries.
[ http://issues.apache.org/jira/browse/JDO-177?page=all ] Andy Jefferson reassigned JDO-177: -- Assign To: Andy Jefferson (was: Erik Bengtson) JPOX ignores JDOHelper.getObjectId in queries. -- Key: JDO-177 URL: http://issues.apache.org/jira/browse/JDO-177 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson JPOX ignores JDOHelper.getObjectId in queries. This bug may be reproduced applying patch JDO-159. The following query returns instances of FullTimeEmployee instead of objectid instances: SELECT JDOHelper.getObjectId(this) FROM org.apache.jdo.tck.pc.company.Person -- 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] Assigned: (JDO-177) JPOX ignores JDOHelper.getObjectId in queries.
[ http://issues.apache.org/jira/browse/JDO-177?page=all ] Andy Jefferson reassigned JDO-177: -- Assign To: Michael Watzek (was: Andy Jefferson) JPOX CVS has been updated to support JDOHelper.getObjectId in the result clause. It now shows up an error in the test. The second query is trying to use a filter of personid = 1, where it should be personid == 1 JPOX ignores JDOHelper.getObjectId in queries. -- Key: JDO-177 URL: http://issues.apache.org/jira/browse/JDO-177 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Michael Watzek JPOX ignores JDOHelper.getObjectId in queries. This bug may be reproduced applying patch JDO-159. The following query returns instances of FullTimeEmployee instead of objectid instances: SELECT JDOHelper.getObjectId(this) FROM org.apache.jdo.tck.pc.company.Person -- 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-211) SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI 'APPLICATIONIDENTITY0.HASHMAP_OBJECT0_STR'.
[ http://issues.apache.org/jira/browse/JDO-211?page=comments#action_12358175 ] Andy Jefferson commented on JDO-211: I see that the MetaData is now, for example field name=HashMapOfObject_String3 table=HASHMAP_OBJECT3_STR join column=IDENTIFIER/ key embedded field name=id primary-key=true column=ID/ field name=intField column=INTVAL/ field name=stringField column=STRINGVAL/ /embedded /key value column=VALUEVAL/ /field That certainly doesnt agree with my definition of a PK specification for the join table. It should be (IMHO) like this join primary-key column name=IDENTIFIER/ column name=ID/ /primary-key /join which nicely defines the colums to be used for the join table. Using fields of an embedded object and specifying primary-key there is not logical to me, and not supported by JPOX either. The JPOX online docs http://www.jpox.org/docs/1_1/constraints.html provides what we support for PK definition, which is that above. SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI 'APPLICATIONIDENTITY0.HASHMAP_OBJECT0_STR'. Key: JDO-211 URL: http://issues.apache.org/jira/browse/JDO-211 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson Attachments: JDO-211.patch Test*MapStringValueCollections there is a mismatch between orm and schema. -- 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-215) Remove order from mapping for HashSetCollections and SetCollections.
[ http://issues.apache.org/jira/browse/JDO-215?page=comments#action_12358181 ] Andy Jefferson commented on JDO-215: I see that the MetaData is now, for example field name=HashSetOfObject1 table=HASHSET_OF_OBJECT1 join column=IDENTIFIER/ element embedded field name=id primary-key=true column=ID/ field name=intField column=INTVAL/ field name=stringField column=STRINGVAL/ /embedded /element /field That certainly doesnt agree with my definition of a PK specification for the join table. It should be (IMHO) like this join primary-key column name=IDENTIFIER/ column name=ID/ /primary-key /join which nicely defines the colums to be used for the join table. Using fields of an embedded object and specifying primary-key there is not logical to me, and not supported by JPOX either. The JPOX online docs http://www.jpox.org/docs/1_1/constraints.html provides what we support for PK definition, which is that above. Remove order from mapping for HashSetCollections and SetCollections. -- Key: JDO-215 URL: http://issues.apache.org/jira/browse/JDO-215 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assignee: Andy Jefferson Attachments: JDO-215.patch The mapping for HashSetCollections and SetCollections incorrectly have order columns. There should not be an ordering specified for the join table since duplicates are not allowed. The mapping for application identity should not need a primary key, since the JDO implementation should be able to figure out that the primary key is part of the Map.key, but the datastore identity mapping does need a primary key (and again, I'd use the id field of SimpleClass as the join table key column. -- 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-211) SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI 'APPLICATIONIDENTITY0.HASHMAP_OBJECT0_STR'.
[ http://issues.apache.org/jira/browse/JDO-211?page=comments#action_12357480 ] Andy Jefferson commented on JDO-211: Hi Michelle, I'm not convinced that it's a JPOX bug here. I'll explain why Let's take the example of MapStringValueCollections, and its field MapOfObject_String3. This is defined as a Map field with join table and with key of SimpleClass, value of String. Both key and value are embedded, so the join table will have * FK back to the owner table (IDENTIFIER) * column for the value * column(s) for the key fields This is all well and good, but is missing one thing. JPOX needs to put a PK on the join table. What are you proposing that it uses ? It doesnt have an id for the (embedded) SimpleClass key. So it needs something else - and in this case it adds this ADPT_PK_IDX column. Is there a field in the key class (SimpleClass) that would give uniqueness ? e.g ID ? In that case you should define the primary-key on the join table to be formed by IDENTIFIER and ID. This should be enough to stop JPOX adding its own PK adapter column (and if it doesnt prevent it then it is indeed a bug in JPOX). If there isn't a field of that nature then you have to have the ADPT_PK_IDX, or the JDO impl needs to be told somehow that it should not create a PK on the join table (which should be the last option IMHO since its a best practice to have one). I noticed that in the TestHashSetCollections/TestSetCollections you added order which avoided this issue. This means that you have a HashSet/Set that can't contain duplicates (since its a Set), and a datastore representation that *can* have dups. Using a join table primary-key specification (like that above) there would have been better IMHO. SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI 'APPLICATIONIDENTITY0.HASHMAP_OBJECT0_STR'. Key: JDO-211 URL: http://issues.apache.org/jira/browse/JDO-211 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson Test*MapStringValueCollections there is a mismatch between orm and schema. -- 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-207) JPOX creates bogus Derby column, e.g. THIS.TREE_MAP_OF_STRING_OBJECO0
[ http://issues.apache.org/jira/browse/JDO-207?page=all ] Andy Jefferson resolved JDO-207: Resolution: Fixed JPOX was imposing a column name length restriction of 30 (for compatibility with DB2 and Derby's previous incarnation - Cloudscape). This is now removed (builds dated 11/11/2005 onwards) and the MapStringKeyTest also results in the same failure as the other key tests. JPOX creates bogus Derby column, e.g. THIS.TREE_MAP_OF_STRING_OBJECO0 - Key: JDO-207 URL: http://issues.apache.org/jira/browse/JDO-207 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson Tests affected: TestHashMapStringKeyCollections TestHashtableStringKeyCollections TestMapStringKeyCollections TestTreeMapStringKeyCollections May be a problem with the mapping. test(org.apache.jdo.tck.models.fieldtypes.TestHashMapStringKeyCollections)javax.jdo.JDODataStoreException: Get request failed : SELECT THIS.HASH_MAP_OF_STRING_OBJECO0 FROM applicationidentity0.HASHMAP_STR_OBJECT84 THIS WHERE 1 = THIS.IDENTIFIER AND THIS.KEYVAL = ? at org.jpox.store.rdbms.scostore.AbstractMapStore.getValue(AbstractMapStore.java:644) at org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:412) at org.jpox.store.rdbms.scostore.AbstractMapStore.putAll(AbstractMapStore.java:299) at org.jpox.store.mapping.MapMapping.postUpdate(MapMapping.java:192) at org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266) at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1931) at org.jpox.store.StoreManager.update(StoreManager.java:780) at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4336) at org.jpox.state.StateManagerImpl.runReachability(StateManagerImpl.java:3099) at org.jpox.AbstractPersistenceManager.preCommit(AbstractPersistenceManager.java:3001) at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:420) at org.apache.jdo.tck.models.fieldtypes.TestHashMapStringKeyCollections.runTest(TestHashMapStringKeyCollections.java:101) at org.apache.jdo.tck.models.fieldtypes.TestHashMapStringKeyCollections.test(TestHashMapStringKeyCollections.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) NestedThrowablesStackTrace: ERROR 42X04: Column 'THIS.HASH_MAP_OF_STRING_OBJECO0' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'THIS.HASH_MAP_OF_STRING_OBJECO0' is not a column in the target table. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ColumnReference.bindExpression(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(Unknown Source) at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown Source) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(Unknown Source) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown Source) at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bind(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at
[jira] Resolved: (JDO-172) JPOX does not support grouping
[ http://issues.apache.org/jira/browse/JDO-172?page=all ] Andy Jefferson resolved JDO-172: Resolution: Fixed Assign To: Andy Jefferson (was: Erik Bengtson) JPOX CVS supports use of the setGrouping() method, and also specification of HAVING via that method. JPOX builds dated 09/11/2005 allow TCK tests ImplicitParameters.setGrouping and SingleString to pass. JPOX does not support grouping -- Key: JDO-172 URL: http://issues.apache.org/jira/browse/JDO-172 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson JPOX does not support grouping. This bug may be reproduced applying patch JDO-157. -- 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] Assigned: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=all ] Andy Jefferson reassigned JDO-194: -- Assign To: Michael Watzek (was: Andy Jefferson) JPOX CVS does now implement implicit variables 9nightly builds dated 06/11/2005 or later), and the test would pass except for the fact that it has some errors. query.jdoql.variables.VariablesAndFields * several of the queries use when they should use * several of the queries use = when they should use == JPOX does not support implicit variables. - Key: JDO-194 URL: http://issues.apache.org/jira/browse/JDO-194 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Michael Watzek JPOX throws an exception executing queries having implicit parameters (see below). The bug may be reproduced executing test case org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE team.contains(employee) employee.firstname == 'emp1First' org.jpox.store.exceptions.NoSuchPersistentFieldException: Field employee does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent at org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) at org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) at org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) at org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) at org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) at org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) at org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) at org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) at org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) at org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) at org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) at org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) at org.jpox.store.query.Query.executeWithMap(Query.java:907) at org.jpox.store.query.Query.executeWithArray(Query.java:887) at org.jpox.store.query.Query.execute(Query.java:819) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:706) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:625) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:601) at org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields.testPositive(VariablesAndFields.java:148) at
[jira] Resolved: (JDO-173) JPOX does not support instanceof operator
[ http://issues.apache.org/jira/browse/JDO-173?page=all ] Andy Jefferson resolved JDO-173: Resolution: Fixed Implemented in JPOX CVS. Test passes with builds dated 05/11/2005 or later JPOX does not support instanceof operator - Key: JDO-173 URL: http://issues.apache.org/jira/browse/JDO-173 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson JPOX does not support instanceof operator. This bug may be reproduced applying patch JDO-158. The following JDO query fails throwing an Exception: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE mentor instanceof org.apache.jdo.tck.pc.company.PartTimeEmployee. org.jpox.store.query.JDOQLQuery$Compiler$ExpressionSyntaxException: The JDOQL query contains an invalid expression at character 8 in mentor instanceof org.apache.jdo.tck.pc.company.PartTimeEmployee at org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:892) at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:566) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:636) at org.jpox.store.query.Query.executeWithMap(Query.java:891) at org.jpox.store.query.Query.executeWithArray(Query.java:871) at org.jpox.store.query.Query.execute(Query.java:803) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:639) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:559) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:535) at org.apache.jdo.tck.query.jdoql.operators.Instanceof.testPositive(Instanceof.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-206) JDOQL test NotEquals comparing floating point numbers
JDOQL test NotEquals comparing floating point numbers - Key: JDO-206 URL: http://issues.apache.org/jira/browse/JDO-206 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting -- 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-198) TestArrayCollections java.lang.IllegalArgumentException: out of field index :28
[ http://issues.apache.org/jira/browse/JDO-198?page=all ] Andy Jefferson resolved JDO-198: Resolution: Fixed This was fixed in JPOX builds 03/11/2005 onwards TestArrayCollections java.lang.IllegalArgumentException: out of field index :28 --- Key: JDO-198 URL: http://issues.apache.org/jira/browse/JDO-198 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson This appears to be a new error message. But see JDO-98. test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)java.lang.IllegalArgumentException: out of field index :28 at org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.jdoCopyField(ArrayCollections.java) at org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.jdoCopyFields(ArrayCollections.java) at org.jpox.state.StateManagerImpl.saveFields(StateManagerImpl.java:936) at org.jpox.state.StateManagerImpl.init(StateManagerImpl.java:580) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1026) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1082) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:93) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-198) TestArrayCollections java.lang.IllegalArgumentException: out of field index :28
[ http://issues.apache.org/jira/browse/JDO-198?page=comments#action_12356749 ] Andy Jefferson commented on JDO-198: Yes, but did you re-enhance your classes since downloading ? The error is in the enhancement, not at runtime. TestArrayCollections java.lang.IllegalArgumentException: out of field index :28 --- Key: JDO-198 URL: http://issues.apache.org/jira/browse/JDO-198 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson This appears to be a new error message. But see JDO-98. test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)java.lang.IllegalArgumentException: out of field index :28 at org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.jdoCopyField(ArrayCollections.java) at org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.jdoCopyFields(ArrayCollections.java) at org.jpox.state.StateManagerImpl.saveFields(StateManagerImpl.java:936) at org.jpox.state.StateManagerImpl.init(StateManagerImpl.java:580) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1026) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1082) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:93) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-171) JPOX violates assertion A14.4-7, allowing keywords as field names w/o qualification
[ http://issues.apache.org/jira/browse/JDO-171?page=all ] Andy Jefferson resolved JDO-171: Resolution: Fixed Assign To: Andy Jefferson (was: Erik Bengtson) Fixed in JPOX CVS - builds dated 02/11/2005 or later JPOX violates assertion A14.4-7, allowing keywords as field names w/o qualification --- Key: JDO-171 URL: http://issues.apache.org/jira/browse/JDO-171 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson JPOX violates assertion A14.4-7 (Keywords are permitted as field names only if they are on the right side of the . in field access expressions). This bug may be reproduced applying patch JDO-157. -- 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] Assigned: (JDO-98) TestArrayCollections: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this
[ http://issues.apache.org/jira/browse/JDO-98?page=all ] Andy Jefferson reassigned JDO-98: - Assign To: Michelle Caisse (was: Andy Jefferson) With JPOX latest build this now fails with test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)javax.jdo.JDOUserException: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 i s declared as a reference type (interface/Object) but no implementation classes of class java.lang.Object have been found! at org.jpox.store.rdbms.table.ColumnCreator.getImplementationNamesForReferenceField(ColumnCreator.java:244) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForReferenceField(ColumnCreator.java:310) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:399) at org.jpox.store.rdbms.table.ColumnCreator.createColumns(ColumnCreator.java:94) consequently the MetaData needs updates so that implementations can map it. TestArrayCollections: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this -- Key: JDO-98 URL: http://issues.apache.org/jira/browse/JDO-98 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Michelle Caisse test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)org.jpox.metadata.InvalidMetaDataException: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this - the elements must be embedded. at org.jpox.metadata.ArrayMetaData.populate(ArrayMetaData.java:106) at org.jpox.metadata.FieldMetaData.populate(FieldMetaData.java:662) at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:697) at org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:635) at org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:399) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:308) at org.jpox.AbstractPersistenceManager.hasMetaDataForPersistenceCapableClass(AbstractPersistenceManager.java:381) at org.jpox.AbstractPersistenceManager.assertPersistenceCapable(AbstractPersistenceManager.java:412) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:950) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1048) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:95) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:197) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106) -- 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-170) JPOX does not detect keywords used as package names
[ http://issues.apache.org/jira/browse/JDO-170?page=all ] Andy Jefferson resolved JDO-170: Resolution: Fixed Assign To: Andy Jefferson (was: Erik Bengtson) Fixed in JPOX CVS (assuming this is the TCK test InvalidUseOfKeywords) JPOX does not detect keywords used as package names --- Key: JDO-170 URL: http://issues.apache.org/jira/browse/JDO-170 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Andy Jefferson When a keyword as a package, JPOX tries to load the corresponding class. This is a bug because assertion A14.4-6 (Keywords must not be used as package names, class names, parameter names, or variable names in queries.) requests that a JDOUserException is thrown. This bug may be reproduced using the patch for JDO-157. -- 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-187) Detach lifecycle listeners are incorrectly implemented
[ http://issues.apache.org/jira/browse/JDO-187?page=comments#action_12332756 ] Andy Jefferson commented on JDO-187: Actually was an issue in InstanceCallbacks and not InstanceLifecycleListener. JPOX CVS now uses the objects the other way around on the postDetach and that part of the test passes. The issue about [java] Sequence verification failed for PRE_DETACH_LISTENER; expected: 1 actual: 2 [java] [java] Sequence verification failed for PRE_DETACH_CALLBACK; expected: 2 actual: 1 [java] remains. This is down to the TCK test making the assumption that the callback will appear before the lifecycle listener. Where is this specifed in the JDO2 spec ? If there's no reference in the spec then it can't be imposed in the TCK. Detach lifecycle listeners are incorrectly implemented -- Key: JDO-187 URL: http://issues.apache.org/jira/browse/JDO-187 Project: JDO Type: Bug Components: tck20 Environment: JPOX Reporter: Craig Russell Assignee: Andy Jefferson The following errors are reported for test case InstanceLifecycleListenerDetach. [java] testDetach(org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerDetach)junit.framework.AssertionFailedError: Assertion A12.15-11 (TestInstanceLifecycleListener) failed: [java] Assertion A12.15-12 (TestInstanceLifecycleListener) failed: in postDetach, target expected [EMAIL PROTECTED], actual null [java] Assertion A12.15-12 (TestInstanceLifecycleListener) failed: in postDetach, target object should be persistent. [java] Assertion A12.15-12 (TestInstanceLifecycleListener) failed: in postDetach, source wasPostDetachCalled() was not true. [java] [java] Sequence verification failed for PRE_DETACH_LISTENER; expected: 1 actual: 2 [java] [java] Sequence verification failed for PRE_DETACH_CALLBACK; expected: 2 actual: 1 [java] [java] at org.apache.jdo.tck.api.instancecallbacks.AbstractInstanceLifecycleListener$InstanceLifecycleListenerImpl.verifyCallbacks(AbstractInstanceLifecycleListener.java:464) [java] at org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerDetach.testDetach(InstanceLifecycleListenerDetach.java:108) [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:120) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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] Assigned: (JDO-186) Attach lifecycle listeners are incorrectly implemented
[ http://issues.apache.org/jira/browse/JDO-186?page=all ] Andy Jefferson reassigned JDO-186: -- Assign To: Craig Russell (was: Andy Jefferson) Actually was an issue in InstanceCallbacks and not InstanceLifecycleListener. JPOX CVS now uses the objects the other way around on the postAttach and that part of the test passes. The issue about [java] Sequence verification failed for PRE_ATTACH_CALLBACK; expected: 2 actual: 0 [java] [java] Sequence verification failed for POST_ATTACH_LISTENER; expected: 3 actual: 2 remains. This seems to be down to the TCK test assuming something about ordering. What is the issue here ? Attach lifecycle listeners are incorrectly implemented -- Key: JDO-186 URL: http://issues.apache.org/jira/browse/JDO-186 Project: JDO Type: Bug Components: tck20 Environment: JPOX Reporter: Craig Russell Assignee: Craig Russell The InstanceLifecycleListenerAttach test case fails with these errors. [java] testAttach(org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach)junit.framework.AssertionFailedError: Assertion A12.15-13 (TestInstanceLifecycleListener) failed: [java] Assertion A12.15-14 (TestInstanceLifecycleListener) failed: in postAttach, source object should be persistent. [java] Assertion A12.15-14 (TestInstanceLifecycleListener) failed: in postAttach, target expected [EMAIL PROTECTED], actual null [java] [java] Sequence verification failed for PRE_ATTACH_CALLBACK; expected: 2 actual: 0 [java] [java] Sequence verification failed for POST_ATTACH_LISTENER; expected: 3 actual: 2 [java] [java] at org.apache.jdo.tck.api.instancecallbacks.AbstractInstanceLifecycleListener$InstanceLifecycleListenerImpl.verifyCallbacks(AbstractInstanceLifecycleListener.java:464) [java] at org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach.testAttach(InstanceLifecycleListenerAttach.java:111) [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:120) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-98) TestArrayCollections: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this
[ http://issues.apache.org/jira/browse/JDO-98?page=comments#action_12332759 ] Andy Jefferson commented on JDO-98: --- JPOX CVS has support for much more in the array world now (like arrays of String, Date, etc, and persisting using a join table). Things like arrays of interfaces are supported partially. I suggest that you give it a try with the latest build TestArrayCollections: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this -- Key: JDO-98 URL: http://issues.apache.org/jira/browse/JDO-98 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)org.jpox.metadata.InvalidMetaDataException: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this - the elements must be embedded. at org.jpox.metadata.ArrayMetaData.populate(ArrayMetaData.java:106) at org.jpox.metadata.FieldMetaData.populate(FieldMetaData.java:662) at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:697) at org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:635) at org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:399) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:308) at org.jpox.AbstractPersistenceManager.hasMetaDataForPersistenceCapableClass(AbstractPersistenceManager.java:381) at org.jpox.AbstractPersistenceManager.assertPersistenceCapable(AbstractPersistenceManager.java:412) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:950) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1048) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:95) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:197) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106) -- 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] 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) Thanks Michelle. Well I'll explain what the problem is, and some options. The test creates an object with many collections and instantiates them as Vectors (as you know). It tries to persist it, and JPOX converts all Collection fields to the equivalent wrapper type for the _instantiated_ type of the field. This is fine. The test then goes back to the datastore and retrieves the persisted object. JPOX has to look at what is in the datastore for each Collection field and create a suitable Collection. At this point it has no idea that the user wants a Vector creating since the instantiated type is not stored in the datastore anywhere. Consequently it knows it has to create a Collection type, and that the user has provided an order, so it create an ArrayList (since that is the JPOX-defined default for Lists). How is JPOX to know that it should instantiate the fields as Vector when it is simply retrieving an object from the datastore and the declared type of the field is Collection ? JPOX calls the default constructor of CollectionCollections and then has to instantiate each field somehow. So it takes a guess. If anyone thinks it should do better, then please please define how. What I would do to the test is change your Vector.elementAt(i) calls to be List.get(i) (since List.get(i) is more generic and does the same thing as Vector.elementAt(i)), and cast the Collection field to a List instead of a Vector. This will work because JPOX (CVS) has given it a List wrapper. Hope that makes sense. 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
[jira] Resolved: (JDO-183) java.lang.ArrayIndexOutOfBoundsException: 0 = 0
[ http://issues.apache.org/jira/browse/JDO-183?page=all ] Andy Jefferson resolved JDO-183: Resolution: Fixed Test now passes with JPOX CVS java.lang.ArrayIndexOutOfBoundsException: 0 = 0 Key: JDO-183 URL: http://issues.apache.org/jira/browse/JDO-183 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson [java] 1) test(org.apache.jdo.tck.models.fieldtypes.TestVectorCollections)java.lang.ArrayIndexOutOfBoundsException: 0 = 0 [java] at java.util.Vector.elementAt(Vector.java:431) [java] at org.apache.jdo.tck.models.fieldtypes.TestVectorCollections.checkValues(TestVectorCollections.java:164) [java] at org.apache.jdo.tck.models.fieldtypes.TestVectorCollections.runTest(TestVectorCollections.java:108) [java] at org.apache.jdo.tck.models.fieldtypes.TestVectorCollections.test(TestVectorCollections.java:71) [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:120) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-182) SQL Exception: No authorized routine named 'LIKE' of type 'FUNCTION' having compatible arguments was found.
[ http://issues.apache.org/jira/browse/JDO-182?page=all ] Andy Jefferson resolved JDO-182: Resolution: Fixed Assign To: Andy Jefferson (was: Erik Bengtson) TestSetCollections and TestHashSetCollections both now pass with JPOX CVS. SQL Exception: No authorized routine named 'LIKE' of type 'FUNCTION' having compatible arguments was found. --- Key: JDO-182 URL: http://issues.apache.org/jira/browse/JDO-182 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Andy Jefferson Affects tests TestSetCollections and TestHashSetCollections [java] ERROR 42884: No authorized routine named 'LIKE' of type 'FUNCTION' having compatible arguments was found. [java] at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) [java] at org.apache.derby.impl.sql.compile.LikeEscapeOperatorNode.bindExpression(Unknown Source) [java] at org.apache.derby.impl.sql.compile.BinaryOperatorNode.bindExpression(Unknown Source) [java] at org.apache.derby.impl.sql.compile.BinaryLogicalOperatorNode.bindExpression(Unknown Source) [java] at org.apache.derby.impl.sql.compile.AndNode.bindExpression(Unknown Source) [java] at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown Source) [java] at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(Unknown Source) [java] at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown Source) [java] at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(Unknown Source) [java] at org.apache.derby.impl.sql.compile.CursorNode.bind(Unknown Source) [java] at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) [java] at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) [java] at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) [java] at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) [java] at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) [java] at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190) [java] at org.jpox.store.rdbms.scostore.AbstractCollectionStore.contains(AbstractCollectionStore.java:271) [java] at org.jpox.store.rdbms.scostore.AbstractSetStore.remove(AbstractSetStore.java:386) [java] at org.jpox.sco.SCOUtils.updateStoreWithCollection(SCOUtils.java:459) [java] at org.jpox.store.mapping.container.CollectionMapping.postUpdate(CollectionMapping.java:291) [java] at org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266) [java] at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1893) [java] at org.jpox.store.StoreManager.update(StoreManager.java:781) [java] at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4338) [java] at org.jpox.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:3057) [java] at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:436) [java] at org.apache.jdo.tck.models.fieldtypes.TestHashSetCollections.runTest(TestHashSetCollections.java:106) [java] at org.apache.jdo.tck.models.fieldtypes.TestHashSetCollections.test(TestHashSetCollections.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:204) [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- 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-192) testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter.
testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter. --- Key: JDO-192 URL: http://issues.apache.org/jira/browse/JDO-192 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Erik provided a patch for this some time ago (~3 weeks). Can someone with the necessary permissions please commit it ? Its bugging me seeing it still there ... -- 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-175) JPOX fails when a query calls String.indexOf
[
http://issues.apache.org/jira/browse/JDO-175?page=comments#action_12331642 ]
Andy Jefferson commented on JDO-175:
This will likely work with latest JPOX CVS, but since this JIRA issue is based
on something that isn't even checked in, it is not possible to test it.
JPOX fails when a query calls String.indexOf
Key: JDO-175
URL: http://issues.apache.org/jira/browse/JDO-175
Project: JDO
Type: Bug
Reporter: Michael Watzek
Assignee: Erik Bengtson
JPOX fails when a query calls String.indexOf. This bug may be reproduced
applying patch JDO-158. The following query throws an exception:
SELECT FROM org.apache.jdo.tck.pc.company.Person WHERE
firstname.indexOf('First') == 4
javax.jdo.JDOUserException: String.indexOf() can only be compared = 0
at
org.jpox.store.expression.IndexOfExpression.toStatementText(IndexOfExpression.java:60)
at org.jpox.store.StatementText.append(StatementText.java:138)
at
org.jpox.store.expression.ScalarExpression.init(ScalarExpression.java:265)
at
org.jpox.store.expression.BooleanExpression.init(BooleanExpression.java:47)
at
org.jpox.store.expression.NumericExpression.eq(NumericExpression.java:63)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1105)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1087)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1075)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1063)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1051)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1033)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1010)
at
org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:888)
at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:566)
at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:636)
at org.jpox.store.query.Query.executeWithMap(Query.java:891)
at org.jpox.store.query.Query.executeWithArray(Query.java:871)
at org.jpox.store.query.Query.execute(Query.java:803)
at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:639)
at
org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:559)
at
org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:535)
at
org.apache.jdo.tck.query.jdoql.methods.SupportedStringMethods.executeQuery(SupportedStringMethods.java:274)
at
org.apache.jdo.tck.query.jdoql.methods.SupportedStringMethods.testIndexOfString(SupportedStringMethods.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.textui.TestRunner.doRun(TestRunner.java:116)
at junit.textui.TestRunner.doRun(TestRunner.java:109)
at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120)
at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95)
--
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-179) Release snapshots of Apache JDO deliverables
Release snapshots of Apache JDO deliverables Key: JDO-179 URL: http://issues.apache.org/jira/browse/JDO-179 Project: JDO Type: Task Components: api20 Reporter: Andy Jefferson The development lifecycle of any project should involve releases of the deliverable software at particular stages. In the case of Apache JDO this means the API 2.0 and the TCK 2.0. The Apache JDO project requires feedback on its development and how complete the API and TCK are. With this in mind it is essential that there are (dated) snapshot releases made available at intervals so that people have something to base comments against, and to develop against. Without such snapshots related projects (JDO implementations, JDO2 reference implementation) will have to make their own snapshots and release these to their users as necessary. This was originally requested back in April 2005. -- 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-180) Publish API 1.1 and API 2.0 javadocs on website
Publish API 1.1 and API 2.0 javadocs on website --- Key: JDO-180 URL: http://issues.apache.org/jira/browse/JDO-180 Project: JDO Type: Task Components: site and infrastructure Reporter: Andy Jefferson A deliverable of the Apache JDO project is to provide the APIs for JDO. Users of JDO-enabled systems need visibility of the JDO APIs in order to develop their systems. It is imperative that the javadocs for these APIs (API 1.1, and API 2.0) are published on the website asap. Without this, JDO vendors have to publish their own version of the API. -- 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] 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] 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
[jira] Commented: (JDO-144) Incorrect value for public Collection CollectionOfDate12
[ http://issues.apache.org/jira/browse/JDO-144?page=comments#action_12331296 ] Andy Jefferson commented on JDO-144: The differences are down to 1. SQL DATE type being used in the schema when it should be using TIMESTAMP. If you want to store a java.util.Date you should use SQL TIMESTAMP. The schema needs changing to do this. This is a TCK issue. 2. Duplicates being thrown away. This is a JPOX issue for Collection type only (Collection is mapped internally to Set) - all other container types should be fine here. 3. Ordering not preserved. This is a JPOX issue for Collection type only (Collection is mapped internally to Set) - all other container types should be fine here. 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 [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] Commented: (JDO-144) Incorrect value for public Collection CollectionOfDate12
[ http://issues.apache.org/jira/browse/JDO-144?page=comments#action_12331312 ] Andy Jefferson commented on JDO-144: Issue 2 and 3 above are now fixed in JPOX CVS - JPOX builds dated 05/10/2005 or later have this. The test now gives Expected and observed do not match!! For element 12, expected = [Thu Jan 01 01:33:27 GMT 1970, Fri Jan 02 01:44:27 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970], actual = [Thu Jan 01 01:00:00 GMT 1970,Fri Jan 02 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970] . For element 13, expected = [Thu Jan 01 01:33:27 GMT 1970, Fri Jan 02 01:44:27 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970, Sun Jan 11 08:24:33 GMT 1970], actual = [Thu Jan 01 01:00:00 GMT 1970,Fri Jan 02 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970,Sun Jan 11 01:00:00 GMT 1970] . For element 18, expected = [2007908.54548, 0.544, 3002323232.545454, 64564645656.78657, 4564565465.2342], actual = [2007908.545480, 0.544000, 3002323232.545454, 64564645656.786570,4564565465.234200] . For element 19, expected = [2007908.54548, 0.544, 3002323232.545454, 64564645656.78657, 4564565465.2342], actual = [2007908.545480, 0.544000, 3002323232.545454, 64564645656.786570, 4564565465.234200] . which seems to come down to issue 1 above in the schema, and to the comparison of floating point fields (which are never likely to be exact after writing to and retrieving from an RDBMS - should do a comparison with an amount +/- IMHO). 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 [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] Updated: (JDO-150) PersistenceManager.retrieve(...) updates to match the JDO2 spec
[ http://issues.apache.org/jira/browse/JDO-150?page=all ] Andy Jefferson updated JDO-150: --- Attachment: patch.txt The attached patch is hopefully adequate. JPOX CVS includes the missing retrieve() method (nightly builds dated 27/09/2005 onwards) so patch can be applied anytime after that and shouldn't break the linkage with JPOX. PersistenceManager.retrieve(...) updates to match the JDO2 spec --- Key: JDO-150 URL: http://issues.apache.org/jira/browse/JDO-150 Project: JDO Type: Task Components: api20 Reporter: Andy Jefferson Assignee: Craig Russell Attachments: patch.txt The JDO2 spec defines PersistenceManager containing :- void retrieve(Object pc, boolean FGOnly); This is currently missing. Also the methods void retrieveAll (Collection pcs, boolean DFGOnly); void retrieveAll (Object[] pcs, boolean DFGOnly); refer to a DFGOnly parameter, whereas it should be FGOnly. Javadocs need similar updates -- 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
