[jira] Assigned: (JDO-206) JDOQL test NotEquals comparing floating point numbers
[ http://issues.apache.org/jira/browse/JDO-206?page=all ] Craig Russell reassigned JDO-206: - Assign To: Erik Bengtson Some tricks need to be used. This test compares a BigDecimal parameter to a floating point field in the database. 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 Assignee: Erik Bengtson 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] Commented: (JDO-218) checkValues() method of *MapStringValueCollections doesn't work
[
http://issues.apache.org/jira/browse/JDO-218?page=comments#action_12358029 ]
Craig Russell commented on JDO-218:
---
It seems like this code has a similar problem in case there is a BigDecimal as
a value.
+String expectedVal = (String)
expected.get(expectedKey);
+String actualValue = (String)
+
actual.get(TestUtil.getBigDecimalKey(expectedKey,
+
actualKeySet));
+if (!expectedVal.equals(actualValue)) {
+sbuf.append(\nFor element + i +
+ expected value = + expectedVal +
+ actual Value = + actualValue);
+ }
Could it be rewritten to use compareTo instead:
+String expectedVal = (String)
expected.get(expectedKey);
+String actualValue = (String)
+
actual.get(TestUtil.getBigDecimalKey(expectedKey,
+
actualKeySet));
+if (expectedVal.equals(actualValue)) {continue;}
if (expectedVal instanceof Comparable
((Comparable)expectedVal.compareTo(actualValue)) == 0) {continue;}
+sbuf.append(\nFor element + i +
+ expected value = + expectedVal +
+ actual Value = + actualValue);
+ }
checkValues() method of *MapStringValueCollections doesn't work
---
Key: JDO-218
URL: http://issues.apache.org/jira/browse/JDO-218
Project: JDO
Type: Bug
Components: tck20
Reporter: Michelle Caisse
Assignee: Michelle Caisse
Attachments: JDO-218.patch
No map fields with BigDecimal values compare okay. There are several
problems.
--
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-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=all ] Craig Russell reassigned JDO-211: - Assign To: Michelle Caisse (was: Andy Jefferson) Combining the metadata for the field, join, key, and value, I come up with this: field name=HashMapOfObject_String3 table=HASHMAP_OBJECT3_STR join column=IDENTIFIER/ primary-key column name=IDENTIFIER/ column name=ID/ /primary-key /join key embedded field name=id column=ID/ field name=intField column=INTVAL/ field name=stringField column=STRINGVAL/ /embedded /key value column=VALUEVAL/ /field This should be a standard, portable mapping for the mapembedded SimpleClass, embedded String case. I will propose to the expert group that a portable mapping for arrays, collections, and maps will include a primary key on the join table. 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: Michelle Caisse 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] Assigned: (JDO-215) Remove order from mapping for HashSetCollections and SetCollections.
[ http://issues.apache.org/jira/browse/JDO-215?page=all ] Craig Russell reassigned JDO-215: - Assign To: Michelle Caisse (was: Andy Jefferson) This is the same issue as JDO-211. So I agree that the metadata should look like: field name=HashSetOfObject1 table=HASHSET_OF_OBJECT1 join column=IDENTIFIER primary-key column name=IDENTIFIER/ column name=ID/ /primary-key /join element embedded field name=id column=ID/ field name=intField column=INTVAL/ field name=stringField column=STRINGVAL/ /embedded /element /field 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: Michelle Caisse 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-215) Remove order from mapping for HashSetCollections and SetCollections.
[ http://issues.apache.org/jira/browse/JDO-215?page=comments#action_12358440 ] Craig Russell commented on JDO-215: --- As discussed on the JDO expert group, the primary-key annotation is only needed for cases where there is an embedded Map key or Set element that doesn't have a unique key field already known. That is, for embedded SimpleClass with datastore identity used as Map keys or Set elements. The other cases have a known unique field that can be used to make the rows unique. For embedded SimpleClass with appication identity, it's the id field. For non-embedded SimpleClass, it's the foreign key reference. 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: Michelle Caisse 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_12358530 ] Craig Russell commented on JDO-211: --- The expert group rejected the notion that a portable mapping for arrays, collections, and maps will include a primary key on the join table. So there is no need in general to include a primary key element. But we still need to map these fields that use an embedded SimpleClass as a Map key or Set element. These fields should include a primary key in the mapping. 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: Michelle Caisse 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-229) Class DeleteCallback must not assume managed relationships.
[
http://issues.apache.org/jira/browse/JDO-229?page=comments#action_12359444 ]
Craig Russell commented on JDO-229:
---
Just a few comments.
1. The line:
lifecycleVerifyer = new LifecycleVerifier(result);
should probably also change the name of the variable, to:
lifecycleVerifier = new LifecycleVerifier(result);
2. The code to clear relationships for the deletePersistentAll problem doesn't
appear to solve the issue. The issue is not relationships FROM the employees,
it's relationships TO the employee that are represented by database constraints.
+ * If instances are employees, then all relationships are cleared.
* If instances are employees, relationships to the employee are cleared.
+employee.setDentalInsurance(null);
employee.getDentalInsurance.setEmployee(null);
+employee.setMedicalInsurance(null);
employee.getMedicalInsurance.setEmployee(null);
+employee.setDepartment(null);
don't need anything
+employee.setFundingDept(null);
don't need anything
+employee.setManager(null);
don't need anything
+employee.setMentor(null);
employee.getMentor().setProtege(null);
+employee.setHradvisor(null);
don't need anything
+employee.setReviewedProjects(new HashSet());
foreach Project p in employee.getReviewedProjects(){p.removeReviewer(employee);}
+employee.setProjects(new HashSet());
foreach Project p in employee.getProjects() {p.removeMember(employee);}
Class DeleteCallback must not assume managed relationships.
---
Key: JDO-229
URL: http://issues.apache.org/jira/browse/JDO-229
Project: JDO
Type: Bug
Components: tck20
Reporter: Michael Watzek
Assignee: Michael Watzek
Attachments: JDO-229.patch
There is a portability issue with test case DeleteCallback:
The test case assumes that a JDO implementation supports managed
relationships, because it deletes instances which are referenced by other
instances. Given that the relationships are represented by foreign keys in
the database for which the delete rule is specified as RESTRICT, the test
will cause errors for JDO implementations which do not support managed
relationships, because it does not nullify those references explicitely,
In order to make the test case portable, it should explicitely nullify
references to all deleted objects first. Afterwards, it should call
Query.deletePersistentAll.
--
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-95) JDO API not compatible with JRE 1.3
[ http://issues.apache.org/jira/browse/JDO-95?page=all ] Craig Russell updated JDO-95: - Fix Version: JDO 2 beta JDO API not compatible with JRE 1.3 --- Key: JDO-95 URL: http://issues.apache.org/jira/browse/JDO-95 Project: JDO Type: Bug Components: api20 Environment: Websphere JDK 1.3.1 JDO API head version JPOX head version Reporter: Erik Bengtson Assignee: Craig Russell Priority: Blocker Fix For: JDO 2 beta API not compatible with JDK 1.3, see exception: java.lang.NoClassDefFoundError: java.util.Currency at javax.jdo.spi.JDOImplHelper.class$(JDOImplHelper.java:552) at javax.jdo.spi.JDOImplHelper.clinit(JDOImplHelper.java:552) at javax.jdo.identity.ObjectIdentity$1.run(ObjectIdentity.java:49) at java.security.AccessController.doPrivileged(Native Method) at javax.jdo.identity.ObjectIdentity.clinit(ObjectIdentity.java:45) at java.lang.Class.forName1(Native Method) at java.lang.Class.forName(Class.java:142) at org.jpox.metadata.MetaDataManager.class$(MetaDataManager.java:1026) at org.jpox.metadata.MetaDataManager.isClassWithoutMetaData(MetaDataManager.java:1021) at org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:361) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:324) at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:420) at org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:635) at org.jpox.enhancer.conf.JDOConfigManager.parseAndRegisterFile(JDOConfigManager.java:60) at org.jpox.enhancer.GeneratorBase.readJDOConfig(GeneratorBase.java:1307) at org.jpox.enhancer.JPOXEnhancer.main(JPOXEnhancer.java:249) Exception in thread main -- 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-124) DTD's require catalog, schema attributes
[ http://issues.apache.org/jira/browse/JDO-124?page=all ] Craig Russell updated JDO-124: -- Fix Version: JDO 2 beta DTD's require catalog, schema attributes Key: JDO-124 URL: http://issues.apache.org/jira/browse/JDO-124 Project: JDO Type: Task Components: api20 Reporter: Andy Jefferson Assignee: Michelle Caisse Fix For: JDO 2 beta The following needs adding to the jdo DTD !ATTLIST jdo catalog CDATA #IMPLIED !ATTLIST jdo schema CDATA #IMPLIED !ATTLIST package catalog CDATA #IMPLIED !ATTLIST package schema CDATA #IMPLIED !ATTLIST class catalog CDATA #IMPLIED !ATTLIST class schema CDATA #IMPLIED !ATTLIST interface catalog CDATA #IMPLIED !ATTLIST interface schema CDATA #IMPLIED The following needs adding to the orm DTD !ATTLIST orm catalog CDATA #IMPLIED !ATTLIST orm schema CDATA #IMPLIED !ATTLIST package catalog CDATA #IMPLIED !ATTLIST package schema CDATA #IMPLIED !ATTLIST class catalog CDATA #IMPLIED !ATTLIST class schema CDATA #IMPLIED !ATTLIST interface catalog CDATA #IMPLIED !ATTLIST interface schema CDATA #IMPLIED -- 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-79) API 20 does not implement all JDOHelper methods in the specification.
[ http://issues.apache.org/jira/browse/JDO-79?page=all ] Craig Russell updated JDO-79: - Fix Version: JDO 2 beta API 20 does not implement all JDOHelper methods in the specification. - Key: JDO-79 URL: http://issues.apache.org/jira/browse/JDO-79 Project: JDO Type: Bug Components: api20 Environment: JDO 2.0 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Methods need to be added to JDOHelper to align with the latest specification. Specifically, methods for getting PersistenceManagerFactory from an InputStream, Resource, and File need to be aligned with the specification. -- 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-80) JDOImplHelper misses new getObjectIdInstance(Class, Object)
[ http://issues.apache.org/jira/browse/JDO-80?page=all ] Craig Russell updated JDO-80: - Fix Version: JDO 2 beta JDOImplHelper misses new getObjectIdInstance(Class, Object) --- Key: JDO-80 URL: http://issues.apache.org/jira/browse/JDO-80 Project: JDO Type: Bug Components: api20 Environment: JDO 2.0 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta The JDO 1 method getObjectIdInstance(Class, String) will be replaced by the new method getObjectIdInstance(Class, Object). Recompiling of implementation classes depending on this class is required. -- 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-76) Method getKeyAsObject() is missing from SingleFieldIdentity
[ http://issues.apache.org/jira/browse/JDO-76?page=all ] Craig Russell updated JDO-76: - Fix Version: JDO 2 beta Method getKeyAsObject() is missing from SingleFieldIdentity --- Key: JDO-76 URL: http://issues.apache.org/jira/browse/JDO-76 Project: JDO Type: Bug Components: api20 Environment: n/a Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta The method getKeyAsObject was added to the spec and not implemented yet. -- 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-76) Method getKeyAsObject() is missing from SingleFieldIdentity
[ http://issues.apache.org/jira/browse/JDO-76?page=all ] Craig Russell updated JDO-76: - Version: JDO 2 beta Method getKeyAsObject() is missing from SingleFieldIdentity --- Key: JDO-76 URL: http://issues.apache.org/jira/browse/JDO-76 Project: JDO Type: Bug Components: api20 Versions: JDO 2 beta Environment: n/a Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta The method getKeyAsObject was added to the spec and not implemented yet. -- 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-38) Remove unneeded imports in api20
[ http://issues.apache.org/jira/browse/JDO-38?page=all ] Craig Russell updated JDO-38: - Fix Version: JDO 2 beta Remove unneeded imports in api20 Key: JDO-38 URL: http://issues.apache.org/jira/browse/JDO-38 Project: JDO Type: Improvement Components: api20 Reporter: Craig Russell Assignee: Craig Russell Priority: Trivial Fix For: JDO 2 beta Unneeded imports in api20 should be removed. -- 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-178) javax.jdo.spi.I18NHelper causes NullPointerException
[ http://issues.apache.org/jira/browse/JDO-178?page=all ]
Craig Russell updated JDO-178:
--
Fix Version: JDO 2 beta
javax.jdo.spi.I18NHelper causes NullPointerException
Key: JDO-178
URL: http://issues.apache.org/jira/browse/JDO-178
Project: JDO
Type: Bug
Components: api11, api20
Environment: Debian GNU/Linux sid
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Jakarta-Tomcat 5.5.9
KODO JDO 3.3.4
Reporter: Marcin Owsiany
Assignee: Craig Russell
Priority: Minor
Fix For: JDO 2 beta
Attachments: i18nhelper.patch, i18nhelperpatch.txt
In the above environment, I encountered exception being thrown on
JDOHelper.getPersistenceManagerFactory(p) invocation. The exception was a
tricky one, because .printStackTrace() called on it caused another exception
to be thrown, forcing me to manually inspect it by iterating on result of
.getStackTrace().
Anyway, here is what I found after a lng battle:
On JDOHelper class init, an I18NHelper instance is instantiated. On that
instantiation, an attempt is made to load a resource bundle, using
ResourceBundle.getBundle(s, locale, classloader). The classloader is obtained
by calling (javax.jdo.spi.I18NHelper.class).getClassLoader(). However in my
case, this getClassLoader() call returned null, which, to my surprise, is
fine according to J2SE API.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getClassLoader()
says that:
Some implementations may use null to represent the bootstrap class
loader. This
method will return null in such implementations if this class was loaded
by the
bootstrap class loader.
Anyway, when that null is passed to ResourceBundle.getBundle, it throws a
NullPointerException.
Furthermore, that exception is wrapped in another exception,
JDOFatalInternalException if I recall correctly, whose superclass' toString()
uses (surprise, surprise) an I18NHelper instance to get the exception
description. This makes it impossible to investigate such exception using
toString() (for example via log4j).
OK, in truth, the above is a simplified version :-) In fact the exception is
saved for later use by I18NHelper, and makes it to the JDO user only when the
JDO implementation being used throws another, possibly unrelated, exception
during its PersistenceManagerFactory instantiation (in my case it was a trial
kodo version throwing a LicenseException). But the exception thrown by the
JDO implementation gets lost, and the user only gets a quite unexpected JDO
exception, which is hard to debug because of the aforementioned attachment of
the exception to I18NHelper.
Fortunately, the fix is quite easy:
--- javax/jdo/spi/I18NHelper.java 2005-10-06 21:26:17.0 +0200
+++ javax/jdo/spi/I18NHelper.java 2005-10-06 21:26:11.0 +0200
@@ -114,7 +114,10 @@
ResourceBundle resourcebundle = (ResourceBundle)bundles.get(s);
if(resourcebundle == null)
{
+if(classloader != null)
resourcebundle = ResourceBundle.getBundle(s, locale,
classloader);
+else
+resourcebundle = ResourceBundle.getBundle(s, locale);
bundles.put(s, resourcebundle);
}
return resourcebundle;
This uses another ResourceBundle method if bootstrap classloader is to be
used. Another way could possibly be to use a thread context classloader
before trying the system classloader, but that's just my guess (I didn't try
if the other classloader turns out non-null).
I hope that my convoluted description can be understood. The above patch
fixes the problem for me.
regards,
Marcin
--
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-117) PM.newObjectIdInstance javadoc description is inadequate to describe the usage
[ http://issues.apache.org/jira/browse/JDO-117?page=all ] Craig Russell updated JDO-117: -- Fix Version: JDO 2 beta PM.newObjectIdInstance javadoc description is inadequate to describe the usage -- Key: JDO-117 URL: http://issues.apache.org/jira/browse/JDO-117 Project: JDO Type: Improvement Components: api20 Reporter: Andy Jefferson Assignee: Craig Russell Priority: Minor Fix For: JDO 2 beta People often rely on javadocs to decide how to use a method (yes, I know they also have the spec). If someone looks at the javadoc for PersistenceManager.newObjectIdInstance(Class, Object) they have pcClass - the Class of the persistence-capable instance key - the value of the key field for single-field identity. This doesn't tell them that the key should be a String (the result of toString() on the id) when using datastore identity or application identity (when not SingleFieldIdentity) and should only be Long/Integer/Byte/Char/etc when using SingleFieldIdentity. -- 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] Reopened: (JDO-150) PersistenceManager.retrieve(...) updates to match the JDO2 spec
[ http://issues.apache.org/jira/browse/JDO-150?page=all ] Craig Russell reopened JDO-150: --- Need to reopen this to assign it to a fix release. 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 Fix For: JDO 2 beta 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
[jira] Reopened: (JDO-213) Update DTD for array element-type
[ http://issues.apache.org/jira/browse/JDO-213?page=all ] Craig Russell reopened JDO-213: --- Need to reopen this to assign fix release. Update DTD for array element-type - Key: JDO-213 URL: http://issues.apache.org/jira/browse/JDO-213 Project: JDO Type: Improvement Components: api20 Reporter: Craig Russell Assignee: Craig Russell To support Object[] and interface[], we need to add attribute element-type to element array. -- 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-213) Update DTD for array element-type
[ http://issues.apache.org/jira/browse/JDO-213?page=all ] Craig Russell updated JDO-213: -- Fix Version: JDO 2 beta Update DTD for array element-type - Key: JDO-213 URL: http://issues.apache.org/jira/browse/JDO-213 Project: JDO Type: Improvement Components: api20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta To support Object[] and interface[], we need to add attribute element-type to element array. -- 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] Reopened: (JDO-55) Inconsistency between API doc and spec
[ http://issues.apache.org/jira/browse/JDO-55?page=all ] Craig Russell reopened JDO-55: -- Need to reopen this issue to assign it to a release. Inconsistency between API doc and spec -- Key: JDO-55 URL: http://issues.apache.org/jira/browse/JDO-55 Project: JDO Type: Bug Components: api20, api11 Reporter: Michael Watzek Assignee: Craig Russell Priority: Trivial Fix For: JDO 2 beta The API doc of PM.getObjectById defines that a JDODataStoreException might be thrown. The spec defines that an JDOObjectNotFoundException might be thrown: API doc: If the codevalidate/code flag is codetrue/code ... If the instance does not exist in the datastore, then a JDODataStoreException is thrown. Spec: If the validate flag is true: ... If there is an instance already in the cache with the same jdo identity as the oid parameter, the instance is not transactional, and the instance does not exist in the datastore, then a JDOObjectNotFoundException is thrown. -- 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-55) Inconsistency between API doc and spec
[ http://issues.apache.org/jira/browse/JDO-55?page=all ] Craig Russell updated JDO-55: - Fix Version: JDO 2 beta Description: The API doc of PM.getObjectById defines that a JDODataStoreException might be thrown. The spec defines that an JDOObjectNotFoundException might be thrown: API doc: If the codevalidate/code flag is codetrue/code ... If the instance does not exist in the datastore, then a JDODataStoreException is thrown. Spec: If the validate flag is true: ... If there is an instance already in the cache with the same jdo identity as the oid parameter, the instance is not transactional, and the instance does not exist in the datastore, then a JDOObjectNotFoundException is thrown. was: The API doc of PM.getObjectById defines that a JDODataStoreException might be thrown. The spec defines that an JDOObjectNotFoundException might be thrown: API doc: If the codevalidate/code flag is codetrue/code ... If the instance does not exist in the datastore, then a JDODataStoreException is thrown. Spec: If the validate flag is true: ... If there is an instance already in the cache with the same jdo identity as the oid parameter, the instance is not transactional, and the instance does not exist in the datastore, then a JDOObjectNotFoundException is thrown. Environment: Inconsistency between API doc and spec -- Key: JDO-55 URL: http://issues.apache.org/jira/browse/JDO-55 Project: JDO Type: Bug Components: api20, api11 Reporter: Michael Watzek Assignee: Craig Russell Priority: Trivial Fix For: JDO 2 beta The API doc of PM.getObjectById defines that a JDODataStoreException might be thrown. The spec defines that an JDOObjectNotFoundException might be thrown: API doc: If the codevalidate/code flag is codetrue/code ... If the instance does not exist in the datastore, then a JDODataStoreException is thrown. Spec: If the validate flag is true: ... If there is an instance already in the cache with the same jdo identity as the oid parameter, the instance is not transactional, and the instance does not exist in the datastore, then a JDOObjectNotFoundException is thrown. -- 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 ] Craig Russell updated JDO-150: -- Fix Version: JDO 2 beta Version: (was: JDO 2 beta) 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 Fix For: JDO 2 beta 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
[jira] Updated: (JDO-230) Fix order of makePersistent() and addTearDownClass() in localSetUp methods
[ http://issues.apache.org/jira/browse/JDO-230?page=all ] Craig Russell updated JDO-230: -- Version: (was: JDO 2 beta) JDO 2 beta has not shipped yet; so this bug should not affect it. Fix order of makePersistent() and addTearDownClass() in localSetUp methods -- Key: JDO-230 URL: http://issues.apache.org/jira/browse/JDO-230 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Michael Watzek Priority: Minor Fix For: JDO 2 beta The order of calls makePersistent() and addTearDownClass() in localSetUp methods is significant: addTearDownClass() must be called before makePersistent(). This ensures that the next test run will cleanup the database. Currently, many tests call makePersistent() before addTearDownClass(). Given that there is data in the database that will cause a duplicate key exception, the database will not be cleaned up, because tear down classes have not been added at the time the exception is thrown. -- 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-150) PersistenceManager.retrieve(...) updates to match the JDO2 spec
[ http://issues.apache.org/jira/browse/JDO-150?page=all ] Craig Russell resolved JDO-150: --- Resolution: Fixed 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 Fix For: JDO 2 beta 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
[jira] Resolved: (JDO-213) Update DTD for array element-type
[ http://issues.apache.org/jira/browse/JDO-213?page=all ] Craig Russell resolved JDO-213: --- Resolution: Fixed Update DTD for array element-type - Key: JDO-213 URL: http://issues.apache.org/jira/browse/JDO-213 Project: JDO Type: Improvement Components: api20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta To support Object[] and interface[], we need to add attribute element-type to element array. -- 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-55) Inconsistency between API doc and spec
[ http://issues.apache.org/jira/browse/JDO-55?page=all ] Craig Russell resolved JDO-55: -- Resolution: Fixed Inconsistency between API doc and spec -- Key: JDO-55 URL: http://issues.apache.org/jira/browse/JDO-55 Project: JDO Type: Bug Components: api20, api11 Reporter: Michael Watzek Assignee: Craig Russell Priority: Trivial Fix For: JDO 2 beta The API doc of PM.getObjectById defines that a JDODataStoreException might be thrown. The spec defines that an JDOObjectNotFoundException might be thrown: API doc: If the codevalidate/code flag is codetrue/code ... If the instance does not exist in the datastore, then a JDODataStoreException is thrown. Spec: If the validate flag is true: ... If there is an instance already in the cache with the same jdo identity as the oid parameter, the instance is not transactional, and the instance does not exist in the datastore, then a JDOObjectNotFoundException is thrown. -- 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-212) Update jdo.dtd for persistent property support
[ http://issues.apache.org/jira/browse/JDO-212?page=all ] Craig Russell resolved JDO-212: --- Fix Version: JDO 2 beta Resolution: Fixed Committed revision 354904. Update jdo.dtd for persistent property support -- Key: JDO-212 URL: http://issues.apache.org/jira/browse/JDO-212 Project: JDO Type: Bug Components: api20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: interfaceDTD.patch, propertydtdpatch.txt From Erik Bengtson Here is a patch to DTD file - add embedded-only attribute to interface - add persistence-modifier attribute to property - allow nesting property element into embedded - allow nesting property element into fetch-group Again, I cannot commit. -- 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-231) The orm.dtd contains #CDATA and extraneous definition of element property
The orm.dtd contains #CDATA and extraneous definition of element property - Key: JDO-231 URL: http://issues.apache.org/jira/browse/JDO-231 Project: JDO Type: Bug Components: api20 Reporter: Craig Russell Assigned to: Craig Russell Fix For: JDO 2 beta Cleanup needed for orm.dtd. -- 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-214) Add a dtd and xsd for jdoquery documents
[ http://issues.apache.org/jira/browse/JDO-214?page=all ] Craig Russell updated JDO-214: -- Attachment: xsd.patch This patch includes both .xsd files (orm.xsd and jdoquery.xsd). Add a dtd and xsd for jdoquery documents Key: JDO-214 URL: http://issues.apache.org/jira/browse/JDO-214 Project: JDO Type: Bug Components: api20 Reporter: Craig Russell Assignee: Craig Russell Attachments: jdoquery_2_0.dtd, xsd.patch JDO queries can be defined in their own files, separate from the jdo or orm files. As such, they need a document descriptor. -- 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-257) Change return type of makePersistent from void to Object
Change return type of makePersistent from void to Object Key: JDO-257 URL: http://issues.apache.org/jira/browse/JDO-257 Project: JDO Type: New Feature Components: api20 Reporter: Craig Russell Assigned to: Craig Russell Fix For: JDO 2 beta The signatures of makePersistent and makePersistentAll are changed to return the persistent instances. This change was adopted by the expert group 8-Dec-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] Updated: (JDO-257) Change return type of makePersistent from void to Object
[ http://issues.apache.org/jira/browse/JDO-257?page=all ] Craig Russell updated JDO-257: -- Attachment: persistencemanager.patch This patch implements the change to the makePersistent apis. Change return type of makePersistent from void to Object Key: JDO-257 URL: http://issues.apache.org/jira/browse/JDO-257 Project: JDO Type: New Feature Components: api20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: persistencemanager.patch The signatures of makePersistent and makePersistentAll are changed to return the persistent instances. This change was adopted by the expert group 8-Dec-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] Commented: (JDO-257) Change return type of makePersistent from void to Object
[ http://issues.apache.org/jira/browse/JDO-257?page=comments#action_12359931 ] Craig Russell commented on JDO-257: --- The javadoc for these methods is weak. Someone needs to add more information regarding the return values and the fact that detached instances are not returned but values are merged from the detached instance to the persistent instances. Change return type of makePersistent from void to Object Key: JDO-257 URL: http://issues.apache.org/jira/browse/JDO-257 Project: JDO Type: New Feature Components: api20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: persistencemanager.patch The signatures of makePersistent and makePersistentAll are changed to return the persistent instances. This change was adopted by the expert group 8-Dec-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] 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_12360385 ] Craig Russell commented on JDO-243: --- Here's the specification: When grouping is specified, each result expression must be one of: an expression contained in the grouping expression; or, an aggregate expression evaluated once per group. The query groups all elements where all expressions specified in setGrouping have the same values. The query result consists of one element per group. I think that automatically adding fields to the grouping clause is likely to change the expected result, and therefore won't be what the user expects. So I believe the spec is correct in requiring an exception to be thrown. 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] Resolved: (JDO-231) The orm.dtd contains #CDATA and extraneous definition of element property
[ http://issues.apache.org/jira/browse/JDO-231?page=all ] Craig Russell resolved JDO-231: --- Resolution: Fixed Committed revision 357359. The orm.dtd contains #CDATA and extraneous definition of element property - Key: JDO-231 URL: http://issues.apache.org/jira/browse/JDO-231 Project: JDO Type: Bug Components: api20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Cleanup needed for orm.dtd. -- 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-202) orm.xsd and unit tests for xsd are missing
[ http://issues.apache.org/jira/browse/JDO-202?page=comments#action_12360680 ] Craig Russell commented on JDO-202: --- This change adds orm.xsd to the jdo implementation, but it has not been tested. Committed revision 357371. orm.xsd and unit tests for xsd are missing -- Key: JDO-202 URL: http://issues.apache.org/jira/browse/JDO-202 Project: JDO Type: Bug Components: api20 Reporter: Michelle Caisse Assignee: Michael Bouschen The xsd is missing from api20/src/dtd/javax/jdo and there is no test for it. Also need a test for jdo.xsd. -- 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-206) JDOQL test NotEquals comparing floating point numbers
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360755 ] Craig Russell commented on JDO-206: --- Changes look good. 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 Assignee: Michael Bouschen Attachments: JDO-206.patch 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] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360759 ] Craig Russell commented on JDO-206: --- The issue here is that Derby treats the FLOAT data type is used to represent both single- and double-precision floating point numbers. To get a single-precision value in the database, you have to use either REAL data type or specify a length on FLOAT. Everywhere we really want a 32-bit floating point number to be stored, we need to specify REAL or FLOAT(24) as the column type. 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 Assignee: Michael Bouschen Attachments: JDO-206.patch 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] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360881 ] Craig Russell commented on JDO-206: --- The change looks good. This sure had me puzzled for quite a while. The root cause of the issue was that the float values in the class were being mapped to FLOAT column types, which are double precision if no length is specified. Float values were converted to double values for both comparisons and storage, so these would work fine. That is, if a float value of e.g. 234.23 were stored, it would be stored as 234.22999572753906. A query with a float parameter of 234.23 would compare the converted double value 234.22999572753906 and it would work. But a query with a BigDecimal parameter of 234.23 would be converted to a double value of 234.23000, which does not compare equal to the column value. The change looks good to check in. 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 Assignee: Michael Bouschen Attachments: JDO-206.patch, JDO-206.patch2 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] Commented: (JDO-241) JPOX returns wrong query result for non-extent queries.
[
http://issues.apache.org/jira/browse/JDO-241?page=comments#action_12360883 ]
Craig Russell commented on JDO-241:
---
The patch looks good.
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
Attachments: JDO-241.patch
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)
at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1189)
at
org.apache.jdo.tck.query.QueryTest.executeJDOQuery(QueryTest.java:1057)
at
org.apache.jdo.tck.query.result.DistinctCandidateInstances.testCollectionQueries(DistinctCandidateInstances.java:129)
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
[jira] Commented: (JDO-244) JPOX generates illegal SQL for having clauses using COUNT.
[ http://issues.apache.org/jira/browse/JDO-244?page=comments#action_12360944 ] Craig Russell commented on JDO-244: --- I don't think the ordering is needed on the first query. Otherwise, looks good. 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
[jira] Commented: (JDO-241) JPOX returns wrong query result for non-extent queries.
[
http://issues.apache.org/jira/browse/JDO-241?page=comments#action_12360950 ]
Craig Russell commented on JDO-241:
---
The spec is clear on this issue (which is specifically being tested). Queries
against a collection return duplicates unless the distinct keyword is used.
spec
A14.6.9-2 [Queries against an extent always consider only distinct candidate
instances, regardless of whether distinct is specified. Queries against a
collection might contain duplicate candidate instances; the distinct keyword
removes duplicates from the candidate collection in this case.]
/spec
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
Attachments: JDO-241.patch
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)
at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1189)
at
org.apache.jdo.tck.query.QueryTest.executeJDOQuery(QueryTest.java:1057
[jira] Commented: (JDO-72) Test api.persistencemanager.OptimisticFailure hangs
[ http://issues.apache.org/jira/browse/JDO-72?page=comments#action_12361013
]
Craig Russell commented on JDO-72:
--
If you tell me what version strategs are supported by JPOX, I'll put the
version information into the metadata. There are four strategies documented,
all of them are required.
This might be a good opportunity for adding supportedOptions that tell which
strategies are supported.
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
[jira] Commented: (JDO-264) Fix issues in maven.xml preventing iut goals from running properly
[ http://issues.apache.org/jira/browse/JDO-264?page=comments#action_12361072 ] Craig Russell commented on JDO-264: --- 0. I think I misunderstood how this worked (defining the properties in the iut.properties instead of maven.xml or another properties file), and I now agree with you. 1. Ok. I understand why you wanted to test the scripts. I think now we need to test the how to run your jdo implementation part of the run rules. Oh, yeah, that's what I'm supposed to do... Good job. Fix issues in maven.xml preventing iut goals from running properly -- Key: JDO-264 URL: http://issues.apache.org/jira/browse/JDO-264 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Michelle Caisse Attachments: enhanceClasspath.patch maven.xml has not been properly tested on an implementation under test (iut). Test and fix any problems encountered. -- 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-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_12361244 ] Craig Russell commented on JDO-220: --- Committed revision 359106. I've changed the test case to use a different persistence manager for each of the test methods. The test fails. There are now two fetch groups: the first group includes only number1 and the second group includes only number2. In the first test method, with a new persistence manager, an instance is queried with fetch group 1 active. This should load only number1. In the second test method, an instance is queried with fetch groups 1 and 2 active. This should load both fields number1 and number2. Then, group2 is removed from the fetch plan and the query is repeated. Now, only field number1 should be loaded. 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] Created: (JDO-267) Query with alias result generates incorrect SQL
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
Assigned to: 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] Created: (JDO-268) org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach fails with new definition of makePersistent instead of attachCopy
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 Assigned to: 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_12361329 ]
Craig Russell commented on JDO-267:
---
Sorry, I should have included the full stack trace and identified the test
case.
I decided to open a new JIRA for this issue because the JIRA that had been
tracking this test case had changed so many times the original description was
no longer descriptive.
Anyway thanks for the comment.
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] Commented: (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=comments#action_12361330 ] Craig Russell commented on JDO-268: --- The behavior of makePersistent should be the same as attachCopy in the case of the parameter being a detached instance. This is the only test case for the attach behavior, pending new test cases being written. 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] Created: (JDO-269) Change setId methods to allow construction of Company Model classes with default constructor
Change setId methods to allow construction of Company Model classes with default constructor Key: JDO-269 URL: http://issues.apache.org/jira/browse/JDO-269 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assigned to: Craig Russell In order to use PersistenceManager.newInstance with the company model classes, we need to enable the setXXXId methods in the root classes. As it is right now, Person p = pm.newInstance(Person.class); p.setPersonId(5) results in IllegalStateException. -- 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-269) Change setId methods to allow construction of Company Model classes with default constructor
[ http://issues.apache.org/jira/browse/JDO-269?page=all ] Craig Russell updated JDO-269: -- Attachment: persistentinterfaces.patch Please review this patch. This patch changes the setXXXId methods to throw IllegalStateException only if the id is already set. Change setId methods to allow construction of Company Model classes with default constructor Key: JDO-269 URL: http://issues.apache.org/jira/browse/JDO-269 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assignee: Craig Russell Attachments: persistentinterfaces.patch In order to use PersistenceManager.newInstance with the company model classes, we need to enable the setXXXId methods in the root classes. As it is right now, Person p = pm.newInstance(Person.class); p.setPersonId(5) results in IllegalStateException. -- 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_12361643 ] Craig Russell commented on JDO-245: --- There is only one thing wrong with this query: the HAVING clause is not a boolean expression. It's ok to have SUM(salary) in the SELECT clause because you can SELECT terms that are either in the GROUPING clause or are aggregates. A14.6.10-1 [When grouping is specified, each result expression must be one of: an expression contained in the grouping expression; or, an aggregate expression evaluated once per group.] 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] 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_12361645 ] Craig Russell commented on JDO-245: --- Actually, I'll correct myself. The SUM(salary) is not correct because salary is not a field in Employee. Again. I think this should be changed to AVG(weeklyhours) to be valid. Then the test case is only testing the HAVING error. 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] 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_12361662 ] Craig Russell commented on JDO-245: --- Yet another comment. The title of this JIRA is the HAVING clause containing fields that are not part of the result clause. Actually, it's legal for any aggregate expression to be in the HAVING clause regardless of whether it is in the result. So maybe we need another positive test for HAVING that has an expression that isn't contained in the SELECT clause. e.g. SELECT department, AVG(weeklyhours) FROM Employee GROUP BY department HAVING COUNT(personid) 1 And another negative test for HAVING that uses a term that's not an aggregate. SELECT department, AVG(weeklyhours) FROM Employee GROUP BY department HAVING middlename != NULL 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] Resolved: (JDO-269) Change setId methods to allow construction of Company Model classes with default constructor
[ http://issues.apache.org/jira/browse/JDO-269?page=all ] Craig Russell resolved JDO-269: --- Fix Version: JDO 2 beta Resolution: Fixed Committed revision 365778. Change setId methods to allow construction of Company Model classes with default constructor Key: JDO-269 URL: http://issues.apache.org/jira/browse/JDO-269 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: persistentinterfaces.patch In order to use PersistenceManager.newInstance with the company model classes, we need to enable the setXXXId methods in the root classes. As it is right now, Person p = pm.newInstance(Person.class); p.setPersonId(5) results in IllegalStateException. -- 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-263) TestArrayCollections: Field ArrayOfBigDecimal12 is stored incorrectly
[ http://issues.apache.org/jira/browse/JDO-263?page=all ] Craig Russell updated JDO-263: -- Summary: TestArrayCollections: Field ArrayOfBigDecimal12 is stored incorrectly (was: 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!) 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] Commented: (JDO-263) TestArrayCollections: Field ArrayOfBigDecimal12 is stored incorrectly
[ http://issues.apache.org/jira/browse/JDO-263?page=comments#action_12362014 ] Craig Russell commented on JDO-263: --- It looks like if the code in org.jpox.store.rdbms.mapping.Blob2RDBMSMapping is simply removed, then the default serialization will be used, and this will do the right thing. Similarly for BigInteger[ ] that has the same issue. 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-259) Write tests for new persistent-nontransactional-dirty behavior assertions
[ http://issues.apache.org/jira/browse/JDO-259?page=all ] Craig Russell reassigned JDO-259: - Assign To: (was: Matthew T. Adams) Write tests for new persistent-nontransactional-dirty behavior assertions - Key: JDO-259 URL: http://issues.apache.org/jira/browse/JDO-259 Project: JDO Type: New Feature Components: tck20 Reporter: Michelle Caisse A5.6.2-4 [If a datastore transaction is begun, commit will write the changes to the datastore with no checking as to the current state of the instances in the datastore. That is, the changes made outside the transaction together with any changes made inside the transaction will overwrite the current state of the datastore.] A5.6.2-6 [If a datastore transaction is begun, rollback will not write any changes to the datastore.] A5.6.2-8 [If an optimistic transaction is begun, commit will write the changes to the datastore after checking as to the current state of the instances in the datastore. The changes made outside the transaction together with any changes made inside the transaction will update the current state of the datastore if the version checking is successful.] A5.6.2-10 [If an optimistic transaction is begun, rollback will not write any changes to the datastore. The persistent-nontransactional-dirty instances will transition according to the RestoreValues flag. ] -- 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-202) orm.xsd and unit tests for xsd are missing
[ http://issues.apache.org/jira/browse/JDO-202?page=comments#action_12362029 ] Craig Russell commented on JDO-202: --- This issue has two parts. The first part is a program that validates xml files according to schema or DTD that is passed in. The program should look for files that have the suffixes .jdo, .orm, and .jdoquery and validate them against both the DTD and schema. For example, javax.jdo.schema.SchemaTest is the JUnit test that looks for files with the pattern positiveXXX.jdo, positiveXXX.orm, positiveXXX.jdoquery, negativeXXX.jdo, negativeXXX.orm, negativeXXX.jdoquery and simply loads them into a standard DOM using a validating parser. All test files named positiveXXX should succeed; tests named negativeXXX should fail to load. The second part is a set of test data that is organized into positive and negative test cases. The union of positive tests should test every feature (each element and attribute) of each of the .orm, .jdo, and .jdoquery schema and DTD. Negative tests will verify for example that no more than one element is permitted if annotated as ? in DTD or maxOccurs=1 in schema. orm.xsd and unit tests for xsd are missing -- Key: JDO-202 URL: http://issues.apache.org/jira/browse/JDO-202 Project: JDO Type: Bug Components: api20 Reporter: Michelle Caisse Assignee: Michael Bouschen The xsd is missing from api20/src/dtd/javax/jdo and there is no test for it. Also need a test for jdo.xsd. -- 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-263) TestArrayCollections: Field ArrayOfBigDecimal12 is stored incorrectly
[ http://issues.apache.org/jira/browse/JDO-263?page=comments#action_12362141 ] Craig Russell commented on JDO-263: --- It didn't appear that we were getting much traction on this issue so Michelle and I played JPOX developer for a day. Nice to hear our investigation was appreciated. I think that for field types of byte[ ] it makes most sense to send it as is to the datastore. For all the other types it is probably best to use Java serialization instead of a proprietary serialization. This is most portable across JDO implementations (most won't use exactly the JPOX algorithm for serializing). But I also agree that some users might want the more efficient JPOX serialization algorithm compared to Java serialization. So your feature request for JPOX still makes sense to me. And I agree with your solution to use the serialisation method when the field is marked as serialised, and byte streams otherwise. 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] Resolved: (JDO-257) Change return type of makePersistent from void to Object
[ http://issues.apache.org/jira/browse/JDO-257?page=all ] Craig Russell resolved JDO-257: --- Resolution: Fixed Committed revision 367855. Change return type of makePersistent from void to Object Key: JDO-257 URL: http://issues.apache.org/jira/browse/JDO-257 Project: JDO Type: New Feature Components: api20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: attachInterfaces.patch, attachcopy.patch, persistencemanager.patch The signatures of makePersistent and makePersistentAll are changed to return the persistent instances. This change was adopted by the expert group 8-Dec-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] Commented: (JDO-275) Split out alltests.conf into several, smaller configurations
[ http://issues.apache.org/jira/browse/JDO-275?page=comments#action_12362592 ] Craig Russell commented on JDO-275: --- Some typos in the comments. +/* The total number of faiures. */ +private int totalTestCount = 0; + +/* The total number of faiures. */ +private int totalFailureCount = 0; Should be +/* The total number of tests. */ +private int totalTestCount = 0; + +/* The total number of failures. */ +private int totalFailureCount = 0; I ran the tests with the new configuration files and got the same numbers. The new tests took 1 minute longer than the old tests (73 minutes vs. 72 minutes). Within the margin of error. Good to go. Split out alltests.conf into several, smaller configurations Key: JDO-275 URL: http://issues.apache.org/jira/browse/JDO-275 Project: JDO Type: Improvement Components: tck20 Reporter: Michael Bouschen Assignee: Michael Bouschen Attachments: splitAllTests.patch Today alltests.conf lists all the JDO TCK test classes (execpt CompletenessTest) in one big configuration. The idea is splitting it out into several, smaller configurations in order to better tell where the problems are. I propose to have 11 new configuration replacing the existing alltests.conf: instancecallback.conf: 16 test classes with 16 test methods org.apache.jdo.tck.instancecallbacks jdohelper.conf: 42 test classes with 43 test methods org.apache.jdo.tck.api.jdohelper pm.conf: 90 test classes with 90 test methods org.apache.jdo.tck.api.persistencemanager org.apache.jdo.tck.api.persistencemanager.cache org.apache.jdo.tck.api.persistencemanager.close org.apache.jdo.tck.api.persistencemanager.extent org.apache.jdo.tck.api.persistencemanager.flags org.apache.jdo.tck.api.persistencemanager.getobject org.apache.jdo.tck.api.persistencemanager.lifecycle pmf.conf: 28 test classes with 37 test methods org.apache.jdo.tck.api.persistencemanagerfactory enhancement.conf: 4 test classes with 31 test methods org.apache.jdo.tck.enhancement org.apache.jdo.tck.api.persistencecapable extents.conf: 13 test classes with 13 test methods org.apache.jdo.tck.extents lifecycle.conf: 9 test classes with 12 test methods org.apache.jdo.tck.lifecycle models.conf: 48 test classes with 49 test methods org.apache.jdo.tck.models.embedded org.apache.jdo.tck.models.fieldtypes org.apache.jdo.tck.models.inheritance query.conf: 64 test classes with 138 test methods org.apache.jdo.tck.query.api org.apache.jdo.tck.query.delete org.apache.jdo.tck.query.result org.apache.jdo.tck.query.sql jdoql.conf: 81 test classes with 108 test methods org.apache.jdo.tck.query.jdoql transactions.conf: 27 test classes with 27 test methods org.apache.jdo.tck.transactions -- 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-277) Change wage in PartTimeEmployee instances to a small number
Change wage in PartTimeEmployee instances to a small number --- Key: JDO-277 URL: http://issues.apache.org/jira/browse/JDO-277 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Priority: Trivial Fix For: JDO 2 beta The test data for PartTimeEmployee includes wage of 13000 and 15000. This test data has been confused with the salary of FullTimeEmployee. I propose changing the test data for PartTimeEmployee wage from 15000 to 15 and from 13000 to 13. -- 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-277) Change wage in PartTimeEmployee instances to a small number
[ http://issues.apache.org/jira/browse/JDO-277?page=all ] Craig Russell updated JDO-277: -- Attachment: parttimeemployee.patch This patch changes the test data to reasonable wage from 15000 to 15 and from 13000 to 13. No effect on test execution with this patch. Change wage in PartTimeEmployee instances to a small number --- Key: JDO-277 URL: http://issues.apache.org/jira/browse/JDO-277 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Priority: Trivial Fix For: JDO 2 beta Attachments: parttimeemployee.patch The test data for PartTimeEmployee includes wage of 13000 and 15000. This test data has been confused with the salary of FullTimeEmployee. I propose changing the test data for PartTimeEmployee wage from 15000 to 15 and from 13000 to 13. -- 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-277) Change wage in PartTimeEmployee instances to a small number
[ http://issues.apache.org/jira/browse/JDO-277?page=all ] Craig Russell updated JDO-277: -- Attachment: parttimeemployee.patch This patch changes all of the test/testdata files that use PartTimeEmployee, per Michael's comments. Change wage in PartTimeEmployee instances to a small number --- Key: JDO-277 URL: http://issues.apache.org/jira/browse/JDO-277 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Priority: Trivial Fix For: JDO 2 beta Attachments: parttimeemployee.patch, parttimeemployee.patch The test data for PartTimeEmployee includes wage of 13000 and 15000. This test data has been confused with the salary of FullTimeEmployee. I propose changing the test data for PartTimeEmployee wage from 15000 to 15 and from 13000 to 13. -- 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-277) Change wage in PartTimeEmployee instances to a small number
[ http://issues.apache.org/jira/browse/JDO-277?page=all ] Craig Russell resolved JDO-277: --- Resolution: Fixed Assign To: Craig Russell Committed revision 368922. Change wage in PartTimeEmployee instances to a small number --- Key: JDO-277 URL: http://issues.apache.org/jira/browse/JDO-277 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Assignee: Craig Russell Priority: Trivial Fix For: JDO 2 beta Attachments: parttimeemployee.patch, parttimeemployee.patch The test data for PartTimeEmployee includes wage of 13000 and 15000. This test data has been confused with the salary of FullTimeEmployee. I propose changing the test data for PartTimeEmployee wage from 15000 to 15 and from 13000 to 13. -- 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-276) TCK maps BigInteger to BIGINT; should be NUMERIC(31)
[ http://issues.apache.org/jira/browse/JDO-276?page=all ] Craig Russell resolved JDO-276: --- Resolution: Fixed Committed revision 368923. TCK maps BigInteger to BIGINT; should be NUMERIC(31) Key: JDO-276 URL: http://issues.apache.org/jira/browse/JDO-276 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assignee: Craig Russell Priority: Minor Fix For: JDO 2 beta Attachments: biginteger.patch The TCK maps values of fields of type BigInteger to Derby column type BIGINT which is actually 64 bit fixed precision (Java long). The BigInteger type should map to NUMERIC(31) that provides more than 64 bits of precision. -- 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-278) Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo
Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo - Key: JDO-278 URL: http://issues.apache.org/jira/browse/JDO-278 Project: JDO Type: Improvement Components: api11, api20, btree, core20, enhancer20, fostore20, query20, ri11, runtime20, tck11, tck20 Reporter: Craig Russell The proposed new standard for naming group ids seems to be to use the package name of the jar contents as the group id where there is a single package prefix. This change would be done prior to the beta release. -- 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-279) Release tck20 as source with a binary dependency on other projects
Release tck20 as source with a binary dependency on other projects -- Key: JDO-279 URL: http://issues.apache.org/jira/browse/JDO-279 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Fix For: JDO 2 beta This proposal would repackage tck20 as a project that has no dependencies on the super-project (../project.xml). It would continue to have binary dependencies on several of the other projects. This allows us to distribute the tck20 including sources to allow users to run the tck without having to use the svn workspace. The sources are needed in order to debug the implementation under test. -- 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-278) Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo
[ http://issues.apache.org/jira/browse/JDO-278?page=all ] Craig Russell updated JDO-278: -- Attachment: groupid.patch This patch updates the group id to javax.jdo (api11 and api20 projects) or org.apache.jdo (for all other projects) and changes the version to SNAPSHOT for all projects. Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo - Key: JDO-278 URL: http://issues.apache.org/jira/browse/JDO-278 Project: JDO Type: Improvement Components: tck20, api20, tck11, api11, ri11, btree, core20, enhancer20, fostore20, query20, runtime20 Reporter: Craig Russell Attachments: groupid.patch The proposed new standard for naming group ids seems to be to use the package name of the jar contents as the group id where there is a single package prefix. This change would be done prior to the beta release. -- 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-278) Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo
[ http://issues.apache.org/jira/browse/JDO-278?page=all ] Craig Russell reassigned JDO-278: - Assign To: Craig Russell Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo - Key: JDO-278 URL: http://issues.apache.org/jira/browse/JDO-278 Project: JDO Type: Improvement Components: tck20, api20, tck11, api11, ri11, btree, core20, enhancer20, fostore20, query20, runtime20 Reporter: Craig Russell Assignee: Craig Russell Attachments: groupid.patch The proposed new standard for naming group ids seems to be to use the package name of the jar contents as the group id where there is a single package prefix. This change would be done prior to the beta release. -- 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-278) Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo
[ http://issues.apache.org/jira/browse/JDO-278?page=all ] Craig Russell updated JDO-278: -- Fix Version: JDO 2 beta Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo - Key: JDO-278 URL: http://issues.apache.org/jira/browse/JDO-278 Project: JDO Type: Improvement Components: tck20, api20, tck11, api11, ri11, btree, core20, enhancer20, fostore20, query20, runtime20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: groupid.patch The proposed new standard for naming group ids seems to be to use the package name of the jar contents as the group id where there is a single package prefix. This change would be done prior to the beta release. -- 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-278) Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo
[ http://issues.apache.org/jira/browse/JDO-278?page=comments#action_12363017 ] Craig Russell commented on JDO-278: --- Please review. This is ready for checkin. Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo - Key: JDO-278 URL: http://issues.apache.org/jira/browse/JDO-278 Project: JDO Type: Improvement Components: tck20, api20, tck11, api11, ri11, btree, core20, enhancer20, fostore20, query20, runtime20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: groupid.patch The proposed new standard for naming group ids seems to be to use the package name of the jar contents as the group id where there is a single package prefix. This change would be done prior to the beta release. -- 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-278) Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo
[ http://issues.apache.org/jira/browse/JDO-278?page=all ] Craig Russell updated JDO-278: -- Attachment: groupid.patch - All the default goals in the maven.xml files now call jar:install instead of jar:install-snapshot. What is the impact of this change? What this does is to omit the creation of the timestamp-named versions of the jar files and pom files that are stored in the local repository. I think that this is appropriate for now, until we have a need for nightly distributions on the distribution site. We can easily change this when we have the requirement. - fostore20/project.xml now includes the dependency on runtime20 twice. Fixed (the duplicate dependency was removed) with the latest patch. - The patch removes the extend clause for ./project.xml from api11/project.xml. Fixed (added back the dependency on ../project.xml) with the latest patch. Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo - Key: JDO-278 URL: http://issues.apache.org/jira/browse/JDO-278 Project: JDO Type: Improvement Components: tck20, api20, tck11, api11, ri11, btree, core20, enhancer20, fostore20, query20, runtime20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: groupid.patch, groupid.patch The proposed new standard for naming group ids seems to be to use the package name of the jar contents as the group id where there is a single package prefix. This change would be done prior to the beta release. -- 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-278) Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo
[ http://issues.apache.org/jira/browse/JDO-278?page=all ] Craig Russell resolved JDO-278: --- Resolution: Fixed Committed revision 36. Change group ids for jdo projects from apache-jdo to javax.jdo and org.apache.jdo - Key: JDO-278 URL: http://issues.apache.org/jira/browse/JDO-278 Project: JDO Type: Improvement Components: tck20, api20, tck11, api11, ri11, btree, core20, enhancer20, fostore20, query20, runtime20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: groupid.patch, groupid.patch The proposed new standard for naming group ids seems to be to use the package name of the jar contents as the group id where there is a single package prefix. This change would be done prior to the beta release. -- 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-264) Fix issues in maven.xml preventing iut goals from running properly
[ http://issues.apache.org/jira/browse/JDO-264?page=comments#action_12363148 ] Craig Russell commented on JDO-264: --- The changes look good. I also don't know why the rename isn't shown in the diff. Fix issues in maven.xml preventing iut goals from running properly -- Key: JDO-264 URL: http://issues.apache.org/jira/browse/JDO-264 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Michelle Caisse Attachments: JDO-264.patch, enhanceClasspath.patch, enhanceClasspath.patch2 maven.xml has not been properly tested on an implementation under test (iut). Test and fix any problems encountered. -- 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-280) Change the test directory to src.
[ http://issues.apache.org/jira/browse/JDO-280?page=all ] Craig Russell resolved JDO-280: --- Resolution: Fixed Assign To: Craig Russell Sendingtck20/maven.xml Sendingtck20/project.properties Sendingtck20/project.xml Adding tck20/src Deleting tck20/test Transmitting file data ... Committed revision 370671. Change the test directory to src. - Key: JDO-280 URL: http://issues.apache.org/jira/browse/JDO-280 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta The use of the test directory to contain sources has become problematic. I propose to change test to src so maven is not confused. When this change is made, the maven.xml, project.properties, and project.xml need to change as well. -- 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-281) TCK doesn't compile with JDK 1.5
[ http://issues.apache.org/jira/browse/JDO-281?page=all ]
Craig Russell resolved JDO-281:
---
Fix Version: JDO 2 beta
Resolution: Fixed
Assign To: Craig Russell
Sending
src/java/org/apache/jdo/tck/api/persistencemanagerfactory/AfterCloseSetMethodsThrowException.java
Sending
src/java/org/apache/jdo/tck/api/persistencemanagerfactory/AfterGetPersistenceManagerNoSetMethodsSucceed.java
Sending
src/java/org/apache/jdo/tck/models/fieldtypes/TestArrayCollections.java
Sending
src/java/org/apache/jdo/tck/models/fieldtypes/TestArrayListCollections.java
Sending
src/java/org/apache/jdo/tck/models/fieldtypes/TestCollectionCollections.java
Transmitting file data .
Committed revision 370679.
TCK doesn't compile with JDK 1.5
Key: JDO-281
URL: http://issues.apache.org/jira/browse/JDO-281
Project: JDO
Type: Bug
Components: tck20
Reporter: Craig Russell
Assignee: Craig Russell
Fix For: JDO 2 beta
When compiling tck20 under JDK 1.5, several errors and warnings.
/Users/clr/testtck/jdo2-tck-SNAPSHOT/src/java/org/apache/jdo/tck/api/persistencemanagerfactory/AfterCloseSetMethodsThrowException.java:177:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
cast to java.lang.Class for a varargs call
cast to java.lang.Class[] for a non-varargs call and to suppress this warning
method =
PersistenceManagerFactory.class.getMethod(methodName, null);
^
/Users/clr/testtck/jdo2-tck-SNAPSHOT/src/java/org/apache/jdo/tck/api/persistencemanagerfactory/AfterCloseSetMethodsThrowException.java:184:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
method.invoke(pmf, null);
^
/Users/clr/testtck/jdo2-tck-SNAPSHOT/src/java/org/apache/jdo/tck/api/persistencemanagerfactory/AfterGetPersistenceManagerNoSetMethodsSucceed.java:210:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
cast to java.lang.Class for a varargs call
cast to java.lang.Class[] for a non-varargs call and to suppress this warning
method =
PersistenceManagerFactory.class.getMethod(methodName, null);
^
/Users/clr/testtck/jdo2-tck-SNAPSHOT/src/java/org/apache/jdo/tck/api/persistencemanagerfactory/AfterGetPersistenceManagerNoSetMethodsSucceed.java:218:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
method.invoke(pmf, null);
^
/Users/clr/testtck/jdo2-tck-SNAPSHOT/src/java/org/apache/jdo/tck/models/fieldtypes/TestArrayCollections.java:180:
compareTo(java.math.BigDecimal) in java.math.BigDecimal cannot be applied to
(java.lang.Object)
if ((expectedBD.compareTo(actualBD) != 0)) {
^
/Users/clr/testtck/jdo2-tck-SNAPSHOT/src/java/org/apache/jdo/tck/models/fieldtypes/TestArrayListCollections.java:175:
compareTo(java.math.BigDecimal) in java.math.BigDecimal cannot be applied to
(java.lang.Object)
if ((bigDecCompareWith.compareTo(bigDecVal) != 0)) {
^
/Users/clr/testtck/jdo2-tck-SNAPSHOT/src/java/org/apache/jdo/tck/models/fieldtypes/TestCollectionCollections.java:165:
compareTo(java.math.BigDecimal) in java.math.BigDecimal cannot be applied to
(java.lang.Object)
if ((bigDecCompareWith.compareTo(bigDecVal) != 0)) {
^
--
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-279) Release tck20 as source with a binary dependency on other projects
[ http://issues.apache.org/jira/browse/JDO-279?page=comments#action_12363458 ] Craig Russell commented on JDO-279: --- I reviewed the new patch mavenDistSupport-2.patch cleaning up the added preGoal and postGoal. I agree that you should apply the patch mavenDistSupport-2.patch to the trunk and to branches/2.0-beta. Release tck20 as source with a binary dependency on other projects -- Key: JDO-279 URL: http://issues.apache.org/jira/browse/JDO-279 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Fix For: JDO 2 beta Attachments: distrib.patch, distrib.patch2, mavenDistSupport-2.patch, mavenDistSupport.patch This proposal would repackage tck20 as a project that has no dependencies on the super-project (../project.xml). It would continue to have binary dependencies on several of the other projects. This allows us to distribute the tck20 including sources to allow users to run the tck without having to use the svn workspace. The sources are needed in order to debug the implementation under test. -- 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-279) Release tck20 as source with a binary dependency on other projects
[ http://issues.apache.org/jira/browse/JDO-279?page=comments#action_12363530 ] Craig Russell commented on JDO-279: --- Hi Michael, I agree to add assertions to the tck20 source distribution. But I'm not as sure that we should send out the iut_jars contents. It's empty in my workspace, and if the release manager has been testing an IUT, why should it be distributed? Release tck20 as source with a binary dependency on other projects -- Key: JDO-279 URL: http://issues.apache.org/jira/browse/JDO-279 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Fix For: JDO 2 beta Attachments: distrib.patch, distrib.patch2, mavenDistSupport-2.patch, mavenDistSupport-3.patch, mavenDistSupport.patch This proposal would repackage tck20 as a project that has no dependencies on the super-project (../project.xml). It would continue to have binary dependencies on several of the other projects. This allows us to distribute the tck20 including sources to allow users to run the tck without having to use the svn workspace. The sources are needed in order to debug the implementation under test. -- 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-279) Release tck20 as source with a binary dependency on other projects
[ http://issues.apache.org/jira/browse/JDO-279?page=comments#action_12363539 ] Craig Russell commented on JDO-279: --- Oops, read it too quickly. I saw include iut_jars and iut_jars/*. My bad. Good to go. Release tck20 as source with a binary dependency on other projects -- Key: JDO-279 URL: http://issues.apache.org/jira/browse/JDO-279 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Fix For: JDO 2 beta Attachments: distrib.patch, distrib.patch2, mavenDistSupport-2.patch, mavenDistSupport-3.patch, mavenDistSupport.patch This proposal would repackage tck20 as a project that has no dependencies on the super-project (../project.xml). It would continue to have binary dependencies on several of the other projects. This allows us to distribute the tck20 including sources to allow users to run the tck without having to use the svn workspace. The sources are needed in order to debug the implementation under test. -- 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-282) Add convenience methods to get persistent instance and detached instance from InstanceLifecycleEvent
[
http://issues.apache.org/jira/browse/JDO-282?page=comments#action_12363558 ]
Craig Russell commented on JDO-282:
---
I'd prefer to avoid the isPreCallback argumment entirely. I think if we add a
line to the specification that the target is only allowed on the postAttach and
postDetach events, then the existence of the target tells you what you need to
know. So the code doesn't need the argument, but can simply return either the
source or target depending on whether target is null.
For example,
+public Object getDetachedInstance() {
boolean isPreCallback = (target == null);
+switch (getEventType()) {
+case DETACH:
+return isPreCallback
+? null // preDetach: no detached instance yet
+: getSource(); // postDetach: source is detached
instance
+case ATTACH:
+return isPreCallback
+? getSource() // preAttach: source is detached
instance
+: target // postAttach: target is detached instance
+}
+
+// for all other events, there is no detached instance
+return null;
+}
Add convenience methods to get persistent instance and detached instance from
InstanceLifecycleEvent
Key: JDO-282
URL: http://issues.apache.org/jira/browse/JDO-282
Project: JDO
Type: Improvement
Components: api20
Reporter: Matthew T. Adams
Assignee: Matthew T. Adams
Attachments: InstanceLifecycleEvent.patch
The source and target object differ as to whether they are the persistent or
detached instance in class InstanceLifecycleEvent depending upon whether the
event object is given in the preDetach, postDetach, preAttach, or postAttach
callbacks. I propose adding two convenience methods that makes it obvious
from the API which object the user is getting.
--
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-283) Change RunRules to match distribution
[ http://issues.apache.org/jira/browse/JDO-283?page=all ] Craig Russell updated JDO-283: -- Attachment: RunRules.html There was a bug in the html in which the indentation of the bullets was wrong. I've fixed this in the latest attachment. This caused much of the confusion. When you add comments (inline is great!) please change the name of the file (e.g. RunRulesMCComments.html) otherwise JIRA thinks you are replacing the file. My attachment is a replacement but your comments should use a different file name. Change RunRules to match distribution - Key: JDO-283 URL: http://issues.apache.org/jira/browse/JDO-283 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 beta Reporter: Craig Russell Assignee: Craig Russell Attachments: RunRules.html, RunRules.html, RunRules.html The RunRules published with the beta don't reflect accurately the structure of the source distribution. Other issues will come up during the beta period as well. -- 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-283) Change RunRules to match distribution
[ http://issues.apache.org/jira/browse/JDO-283?page=all ] Craig Russell updated JDO-283: -- Attachment: RunRules.html This is the proposed RunRules for the final beta. Change RunRules to match distribution - Key: JDO-283 URL: http://issues.apache.org/jira/browse/JDO-283 Project: JDO Type: Bug Components: tck20 Versions: JDO 2 beta Reporter: Craig Russell Assignee: Craig Russell Attachments: RunRules.html, RunRules.html, RunRules.html, RunRules.html, RunRulesMCComments.html The RunRules published with the beta don't reflect accurately the structure of the source distribution. Other issues will come up during the beta period as well. -- 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-282) Add convenience methods to get persistent instance and detached instance from InstanceLifecycleEvent
[ http://issues.apache.org/jira/browse/JDO-282?page=comments#action_12363868 ] Craig Russell commented on JDO-282: --- Looks good to go. Add convenience methods to get persistent instance and detached instance from InstanceLifecycleEvent Key: JDO-282 URL: http://issues.apache.org/jira/browse/JDO-282 Project: JDO Type: Improvement Components: api20 Reporter: Matthew T. Adams Assignee: Matthew T. Adams Attachments: InstanceLifecycleEvent.java.2.patch, InstanceLifecycleEvent.patch The source and target object differ as to whether they are the persistent or detached instance in class InstanceLifecycleEvent depending upon whether the event object is given in the preDetach, postDetach, preAttach, or postAttach callbacks. I propose adding two convenience methods that makes it obvious from the API which object the user is getting. -- 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-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364692 ] Craig Russell commented on JDO-246: --- Michael interprets the specification as I had intended when I wrote it. I'm willing to clarify the specification if needed. JPOX eliminates duplicates in the query result although DISTINCT is not specified. -- Key: JDO-246 URL: http://issues.apache.org/jira/browse/JDO-246 Project: JDO Type: Bug Components: tck20 Reporter: Michael Watzek Assignee: Erik Bengtson Test case NPEInResultExpr fails because the result of the query below is expected to contain duplicates. JPOX eliminates the duplicates. 14:22:55,046 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT employee.manager.lastname FROM org.apache.jdo.tck.pc.company.Department WHERE employees.contains(employee) VARIABLES Employee employee 14:22:55,078 (main) DEBUG [org.apache.jdo.tck] - Query result: [emp2Last, null] 14:22:55,078 (main) DEBUG [org.apache.jdo.tck] - Wrong query result: expected: [emp2Last, null, emp2Last, emp2Last, emp2Last] got: [emp2Last, null] 14:22:55,078 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest: junit.framework.AssertionFailedError: Assertion A14.6.9-4 (NPEInResultExpr) failed: Wrong query result: expected: [emp2Last, null, emp2Last, emp2Last, emp2Last] got: [emp2Last, 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.queryFailed(QueryTest.java:500) at org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder(QueryTest.java:485) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1189) 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.NPEInResultExpr.testPositive(NPEInResultExpr.java:106) 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-286) Convert unnamed constraints to named constraints in company model
[ http://issues.apache.org/jira/browse/JDO-286?page=comments#action_12364962 ] Craig Russell commented on JDO-286: --- Looks good. A couple of comments. 1. You have some random changes not related to this JIRA issue in your workspace. 2. Could you change tabs to spaces? The indents are wrong for some of the sql, e.g. +CONSTRAINT EMPS_DEPARTMENT FOREIGN KEY (DEPARTMENT) + REFERENCES departments (DATASTORE_IDENTITY), +CONSTRAINT EMPS_FUNDINGDEPT FOREIGN KEY (FUNDINGDEPT) + REFERENCES departments (DATASTORE_IDENTITY), Convert unnamed constraints to named constraints in company model - Key: JDO-286 URL: http://issues.apache.org/jira/browse/JDO-286 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Michelle Caisse Priority: Minor Attachments: constraint.patch Named constraints can assist in debugging. Derby constraint numbering is uninformative. -- 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-279) Release tck20 as source with a binary dependency on other projects
[ http://issues.apache.org/jira/browse/JDO-279?page=all ] Craig Russell resolved JDO-279: --- Resolution: Fixed Assign To: Craig Russell Release tck20 as source with a binary dependency on other projects -- Key: JDO-279 URL: http://issues.apache.org/jira/browse/JDO-279 Project: JDO Type: Improvement Components: tck20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: distrib.patch, distrib.patch2, mavenDistSupport-2.patch, mavenDistSupport-3.patch, mavenDistSupport.patch This proposal would repackage tck20 as a project that has no dependencies on the super-project (../project.xml). It would continue to have binary dependencies on several of the other projects. This allows us to distribute the tck20 including sources to allow users to run the tck without having to use the svn workspace. The sources are needed in order to debug the implementation under test. -- 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-179) Release snapshots of Apache JDO deliverables
[ http://issues.apache.org/jira/browse/JDO-179?page=all ] Craig Russell resolved JDO-179: --- Fix Version: JDO 2 beta Resolution: Fixed The snapshot as of the end of January was released. The next release should be the final one. 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 Assignee: Craig Russell Fix For: JDO 2 beta 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] Resolved: (JDO-283) Change RunRules to match distribution
[ http://issues.apache.org/jira/browse/JDO-283?page=all ] Craig Russell resolved JDO-283: --- Fix Version: JDO 2 beta Resolution: Fixed This issue was fixed with a respin of the beta bits. Change RunRules to match distribution - Key: JDO-283 URL: http://issues.apache.org/jira/browse/JDO-283 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assignee: Craig Russell Fix For: JDO 2 beta Attachments: RunRules.html, RunRules.html, RunRules.html, RunRules.html, RunRulesMCComments.html The RunRules published with the beta don't reflect accurately the structure of the source distribution. Other issues will come up during the beta period as well. -- 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-288) Update DTD, XSD, and FetchPlan.java for fetch plan updates
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 Assigned to: Craig Russell Fix For: JDO 2 rc1 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] Updated: (JDO-290) Copy properties configuration files to logs directory
[ http://issues.apache.org/jira/browse/JDO-290?page=all ] Craig Russell updated JDO-290: -- Fix Version: JDO 2 rc1 (was: JDO 2 beta) Version: JDO 2 beta (was: JDO 2 rc1) Copy properties configuration files to logs directory --- Key: JDO-290 URL: http://issues.apache.org/jira/browse/JDO-290 Project: JDO Type: Improvement Components: tck20 Versions: JDO 2 beta Reporter: Michelle Caisse Assignee: Michelle Caisse Fix For: JDO 2 rc1 In order to provide complete documentation for a test run, we should copy relevant configuration files to the logs directory. These are the files that should be copied: tck20/build.properties tck20/project.properties tck20/maven.xml tck20//project.xml tck20/src/conf/iut-pmf.properties tck20/src/conf/jdori-pmf.properties -- 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-148) Update docs to explain how to run a single test or custom list of tests
[ http://issues.apache.org/jira/browse/JDO-148?page=all ] Craig Russell updated JDO-148: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Update docs to explain how to run a single test or custom list of tests --- Key: JDO-148 URL: http://issues.apache.org/jira/browse/JDO-148 Project: JDO Type: Improvement Components: tck20 Versions: JDO 2 beta Reporter: Matthew T. Adams Assignee: Matthew T. Adams Fix For: JDO 2 rc1 We need to add to the documentation to better explain how to run a single test or a custom set of tests. -- 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-191) Add test for PersistenceManager.getDataStoreConnection()
[ http://issues.apache.org/jira/browse/JDO-191?page=all ] Craig Russell updated JDO-191: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Add test for PersistenceManager.getDataStoreConnection() Key: JDO-191 URL: http://issues.apache.org/jira/browse/JDO-191 Project: JDO Type: Test Components: tck20 Versions: JDO 2 beta Environment: TCK Reporter: Craig Russell Fix For: JDO 2 rc1 A12.16-1 [JDOConnection getDataStoreConnection(); If this method is called while a datastore transaction is active, the object returned will be enlisted in the current transaction. If called in an optimistic transaction before flush has been called, or outside an active transaction, the object returned will not be enlisted in any transaction.]] The tests use the PCPoint class and a jdbc Connection. The first test verifies that an object inserted into the PCPoint table during a transaction is visible by getObjectById in the same transaction. The second test verifies that an object inserted into the PCPoint table outside a transaction is visible in the next transaction. The test needs to work with the jdbc library from the standard JDK 1.3 (JDBC 2.0). -- 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-141) Add getObjectsById tests
[ http://issues.apache.org/jira/browse/JDO-141?page=all ] Craig Russell updated JDO-141: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Add getObjectsById tests Key: JDO-141 URL: http://issues.apache.org/jira/browse/JDO-141 Project: JDO Type: Test Components: tck20 Versions: JDO 2 beta Environment: TCK Reporter: Craig Russell Fix For: JDO 2 rc1 12.5.6-17 [Collection getObjectsById (Collection oids); Object[] getObjectsById (Object[] oids); Collection getObjectsById (Collection oids, boolean validate); Object[] getObjectsById (Object[] oids, boolean validate); The getObjectsById method attempts to find instances in the cache with the specified JDO identities. The elements of the oids parameter object might have been returned by earlier calls to getObjectId or getTransactionalObjectId, or might have been constructed by the application. If a method with no validate parameter is used, the method behaves exactly as the correspond ing method with the validate flag set to true. If the Object[] form of the method is used, the returned objects correspond by position with the object ids in the oids parameter. If the Collection form of the method is used, the iterator over the returned Collection returns instances in the same order as the oids returned by an iterator over the parameter Collection. The cardinality of the return value is the same as the cardinality of the oids parameter. ] The test case api.persistencemanager.GetObjectsById needs a test method per API per validate parameter, or six altogether. testCollection, testArray, testCollectionValidateTrue, testCollectionValidateFalse, testArrayValidateTrue, testArrayValidateFalse. The setUp method creates 50 persistent instances of type PCPoint and stores the ids in an ArrayList and the instances in a separate ArrayList. The test cases getObjectsById and verify that the objects returned match the objects that are in the object list. There are no negative tests. -- 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-202) orm.xsd and unit tests for xsd are missing
[ http://issues.apache.org/jira/browse/JDO-202?page=all ] Craig Russell updated JDO-202: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta orm.xsd and unit tests for xsd are missing -- Key: JDO-202 URL: http://issues.apache.org/jira/browse/JDO-202 Project: JDO Type: Bug Components: api20 Versions: JDO 2 beta Reporter: Michelle Caisse Assignee: Michael Bouschen Fix For: JDO 2 rc1 Attachments: schematest.patch The xsd is missing from api20/src/dtd/javax/jdo and there is no test for it. Also need a test for jdo.xsd. -- 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-272) Create tests for section 12.6.8, detachment behavior
[ http://issues.apache.org/jira/browse/JDO-272?page=all ] Craig Russell updated JDO-272: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Create tests for section 12.6.8, detachment behavior Key: JDO-272 URL: http://issues.apache.org/jira/browse/JDO-272 Project: JDO Type: Test Components: tck20 Versions: JDO 2 beta Reporter: Matthew T. Adams Assignee: Matthew T. Adams Fix For: JDO 2 rc1 Write tests for assertions in section 12.6.8 Detaching and attaching instances, including simple detachable shopping cart object model. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JDO-258) Write tests for new persistent-nontransactional-dirty lifecycle assertions
[ http://issues.apache.org/jira/browse/JDO-258?page=all ] Craig Russell updated JDO-258: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Write tests for new persistent-nontransactional-dirty lifecycle assertions -- Key: JDO-258 URL: http://issues.apache.org/jira/browse/JDO-258 Project: JDO Type: New Feature Components: tck20 Versions: JDO 2 beta Reporter: Michelle Caisse Assignee: Michael Watzek Fix For: JDO 2 rc1 A5.6.2-3 [A persistent-nontransactional-dirty instance transitions to hollow if it is the parameter of evict or evictAll. This allows the application to remove instances from the set of instances whose state is to be committed to the datastore.] A5.6.2-5 [The persistent-nontransactional-dirty instances will transition according to the RetainValues flag. With the RetainValues flag set to true, persistent-nontransactional-dirty instances will transition to persistent-nontransactional. With the RetainValues flag set to false, persistent-nontransactional-dirty instances will transition to hollow. ] A5.6.2-7 [The persistent-nontransactional-dirty instances will transition according to the RestoreValues flag. With the RestoreValues flag set to true, persistent-nontransactional-dirty instances will make no state transition, but the fields will be restored to their values as of the beginning of the transaction, and any changes made within the transaction will be discarded. With the RestoreValues flag set to false, persistent-nontransactional-dirty instances will transition to hollow.] A5.6.2-9 [The persistent-nontransactional-dirty instances will transition according to the RetainValues flag. With the RetainValues flag set to true, persistent-nontransactional-dirty instances will transition to persistent-nontransactional. With the RetainValues flag set to false, persistent-nontransactional-dirty instances will transition to hollow.] A5.6.2-11 [With the RestoreValues flag set to true, persistent-nontransactional-dirty instances will make no state transition, but the fields will be restored to their values as of the beginning of the transaction, and any changes made within the transaction will be discarded. With the RestoreValues flag set to false, persistent-nontransactional-dirty instances will transition to hollow.] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JDO-190) Add test for PersistenceManagerFactory.getDataStoreCache()
[ http://issues.apache.org/jira/browse/JDO-190?page=all ] Craig Russell updated JDO-190: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Add test for PersistenceManagerFactory.getDataStoreCache() -- Key: JDO-190 URL: http://issues.apache.org/jira/browse/JDO-190 Project: JDO Type: Test Components: tck20 Versions: JDO 2 beta Environment: TCK Reporter: Craig Russell Fix For: JDO 2 rc1 A11.8-1 [To obtain a reference to the cache manager, the getDataStoreCache() method of PersistenceManagerFactory is used. DataStoreCache getDataStoreCache(); If there is no second-level cache, the returned instance silently does nothing.] The test calls getDataStoreCache() and verifies that the returned instance is not null. -- 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-238) Timing bug in TCK test case ThreadSafe
[ http://issues.apache.org/jira/browse/JDO-238?page=all ] Craig Russell updated JDO-238: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Timing bug in TCK test case ThreadSafe -- Key: JDO-238 URL: http://issues.apache.org/jira/browse/JDO-238 Project: JDO Type: Bug Components: tck11, tck20 Versions: JDO 2 beta Reporter: Michael Bouschen Assignee: Martin Zaun Priority: Minor Fix For: JDO 2 rc1 The TCK test ThreadSafe runs multiple threads, where each thread tries to persist the same pc instance using its own PM. The expected behavior is that one thread succeeds persisting the pc instance and stores it at transaction commit. All other threads should result in a JDOException because the pc instance is already bound to a different PM. All threads close the PM at the end. Now, it might happen that the succeeding thread closes the PM before a parallel thread tries to persist the pc instance. The behavior of pm.makePersistence for a pc instance bound to a closed pm is not specified, so it does not necessarily result in an exception. The test case should be changed such that the succeeding thread waits for all the other threads before closing the PM. Please note, the solution must be robust enough to avoid a deadlock situation even if an erroneous JDO implementation would allow multiple threads to succeed persisting the pc instance. -- 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-273) Create tests for sections 5.5.8 5.5.9, detachment lifecycle
[ http://issues.apache.org/jira/browse/JDO-273?page=all ] Craig Russell updated JDO-273: -- Fix Version: JDO 2 rc1 Version: JDO 2 beta Create tests for sections 5.5.8 5.5.9, detachment lifecycle - Key: JDO-273 URL: http://issues.apache.org/jira/browse/JDO-273 Project: JDO Type: Test Components: tck20 Versions: JDO 2 beta Reporter: Matthew T. Adams Assignee: Michael Watzek Fix For: JDO 2 rc1 Attachments: JDO-273.patch Write tests for assertions in sections 5.5.8 Detached-clean, 5.5.9 Detached-dirty. -- 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
