[jira] Updated: (JDO-192) testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter.
[ http://issues.apache.org/jira/browse/JDO-192?page=all ] Michelle Caisse updated JDO-192: Attachment: JDO-192.patch I reviewed the patch on 10/4 and it looks good. Please go ahead and check it in. testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter. --- Key: JDO-192 URL: http://issues.apache.org/jira/browse/JDO-192 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Attachments: JDO-192.patch Erik provided a patch for this some time ago (~3 weeks). Can someone with the necessary permissions please commit it ? Its bugging me seeing it still there ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JDO-192) testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter.
[ http://issues.apache.org/jira/browse/JDO-192?page=all ] Michelle Caisse reassigned JDO-192: --- Assign To: Erik Bengtson testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter. --- Key: JDO-192 URL: http://issues.apache.org/jira/browse/JDO-192 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assignee: Erik Bengtson Attachments: JDO-192.patch Erik provided a patch for this some time ago (~3 weeks). Can someone with the necessary permissions please commit it ? Its bugging me seeing it still there ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Apache JIRA : project JDO - disappearing issues
Hi, some news: the two issues Andy resolved yesterday (JDO-170 and JDO-174) are back on the list. But now a couple of subcomponents disappeared. The BROWSE PROJECT page only lists tck11, tck20 and No Component. Any idea? Regards Michael Hi Andy, yes, I figured out the same and just started my mail composer, but you were faster :-). I miss a couple of JDO Jira issues. There is an All filter under Preset Filters on BrowseProject page that is supposed to show all the JDO issues (no matter whether they are resolved or not): http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidepid=10630 It lists 153 issues, but the latest issue has the number 192. Actually issues JDO-143 - JDO-181 do not show up in the list. Some of these are still open, e.g. http://issues.apache.org/jira/browse/JDO-161. I compared the detailed view of JDO-161 with one of the non disappearing issues, but I cannot see any difference. Regards Michael Why is it that when I sometimes look at Apache JIRA I find that issues are maybe no longer there, then I look back 10 mins later they appear. Seems like Apache have some process that reloads up JIRA every so often. Can anyone confirm what is actually going on with your JIRA ? I look today and find pretty much none of the Query issues that Michael (Watzek) raised, yet they were there yesterday (no, its not a user preference issue - this is from a bookmarked page that shows all issues for the JDO project). I'm wondering how are people supposed to develop systems when the issue tracker is unreliable so no one knows the issues ? hm -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Apache JIRA : project JDO - disappearing issues
I see the same thing. Very weird. -- Michelle Michael Bouschen wrote: Hi, some news: the two issues Andy resolved yesterday (JDO-170 and JDO-174) are back on the list. But now a couple of subcomponents disappeared. The BROWSE PROJECT page only lists tck11, tck20 and No Component. Any idea? Regards Michael Hi Andy, yes, I figured out the same and just started my mail composer, but you were faster :-). I miss a couple of JDO Jira issues. There is an All filter under Preset Filters on BrowseProject page that is supposed to show all the JDO issues (no matter whether they are resolved or not): http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidepid=10630 It lists 153 issues, but the latest issue has the number 192. Actually issues JDO-143 - JDO-181 do not show up in the list. Some of these are still open, e.g. http://issues.apache.org/jira/browse/JDO-161. I compared the detailed view of JDO-161 with one of the non disappearing issues, but I cannot see any difference. Regards Michael Why is it that when I sometimes look at Apache JIRA I find that issues are maybe no longer there, then I look back 10 mins later they appear. Seems like Apache have some process that reloads up JIRA every so often. Can anyone confirm what is actually going on with your JIRA ? I look today and find pretty much none of the Query issues that Michael (Watzek) raised, yet they were there yesterday (no, its not a user preference issue - this is from a bookmarked page that shows all issues for the JDO project). I'm wondering how are people supposed to develop systems when the issue tracker is unreliable so no one knows the issues ? hm
Re: Query : setRange clarification
Hi Andy, I recently ran into the same issue and sent out an email to the jdo experts. I should have cc'ed the jdo-dev alias, sorry for that. Craig replied that the TO keyword has been removed from Chapter 14 and its use in the BNF (chapter 24) is an oversight. So the correct syntax is: RANGE fromPosition, toPosition Regards Michael Hi, in the latest spec 09/09 I see that we have the new setRange(String) method. I see that the single-string syntax in chapter 14 for the range is RANGE fromPosition,toPosition but then in chapter 24 I see that we have RANGE fromPosition TO toPosition with a TO keyword. Which one is correct ? The one in Chapter 24 is what was originally the accepted syntax and what JPOX implements currently. Thanks. -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: build failed
Hi Karan, thanks for the pointer. I just checked ibiblio http://www.ibiblio.org/maven/antlr/jars/ and antlr-2.7.5.jar is back. The md5 file antlr-2.7.5.jar.md5 is missing, but the build works w/o the md5 file. Regards Michael Michael, Brett Porter is the guy I know of. [EMAIL PROTECTED] Regards On 10/22/05, Michael Bouschen [EMAIL PROTECTED] wrote: Hi Karan, Hi Michael, I also had the same impression that once something is uploaded on ibiblio, it will not be removed. So what should be done about it? Does a request need to be sent to the maintainer of maven to upload antlr2.7.5 on ibiblio? Do you know who we need to contact? Otherwise, I need to check whether using antlrall-2.7.4 is ok. Regards Michael On 10/22/05, Michael Bouschen [EMAIL PROTECTED] wrote: Hi, I found the following message talink about cleaning up ibiblio: http://www.mail-archive.com/dev@maven.apache.org/msg39867.html It lists files in ibiblio that are not in the maven staging repository at codehaus. This list includes antlr-2.7.5.jar. Regards Michael Hi Karan, this is really strange! In August I changed the dependency from antlr-2.7.3 to antlr-2.7.5, because 2.7.5 was available on ibiblio, but not version 2.7.3. I'm surprised because I thought once a version is on ibiblio it will never be removed. I never tested with version 2.7.4, but I know that we need at least 2.7.3, because there are problems with the generated lexer when using 2.7.2 or earlier. We should try to find out why version 2.7.5 disappeared from ibiblio before we change the dependency. For now I propose you download antlr-2.7.5.jar directly from http://www.antlr.org/download.html and store in in your local repository. Regards Michael Hi, Tried to do maven jdo11.build and got the following error: BUILD FAILED File.. /home/karan/.maven/cache/maven-multiproject-plugin-1.3.1 /plugin.jelly Element... maven:reactor Line.. 217 Column 9 The build cannot continue because of the following unsatisfied dependency: antlr-2.7.5.jar (try downloading from http://www.antlr.org/download.html) http://www.antlr.org/download.html%29 I looked up the project.xml files of jdo11 projects and found a reference to antlr2.7.5. Now, Ibiblio does not host 2.7.5 version, which means that we need to explicitly download this file or do we need to add another remote repository to our path which points to antlr 2.7.5. I know that there was some issue regarding antlr2.7.5 earlier also, but cannot remember what exactly was the issue and the solution to it. But do we really need antlr2.7.5. Ibiblio is currently hosting the following jar files: antlr-2.7.2.jar antlrall-2.7.4.jar If 2.7.5 is not needed then i can submit a patch and fix this issue (i thought this thing was fixed earlier). -- Karan Malhi -- Michael Bouschen [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED] http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin -- Karan Malhi -- Michael Bouschen [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED] http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin -- Karan Malhi -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: [jira] Assigned: (JDO-192) testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter.
Hi Michelle, It seems that I dont have rights to commit even using the https Quoting Michelle Caisse (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/JDO-192?page=all ] Michelle Caisse reassigned JDO-192: --- Assign To: Erik Bengtson testRetrieve : has incorrect parameter specification to PM.retrieve() in terms of the fgOnly parameter. --- Key: JDO-192 URL: http://issues.apache.org/jira/browse/JDO-192 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assignee: Erik Bengtson Attachments: JDO-192.patch Erik provided a patch for this some time ago (~3 weeks). Can someone with the necessary permissions please commit it ? Its bugging me seeing it still there ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Assertion A14.6-21 (Query.getFetchPlan)
Hi Craig, Hi Michael, The relevant bit of the specification is regarding jdoPostLoad. A10.1-2 [This method is not modified by the enhancer.] So whatever is done in jdoPostLoad, the implementation will not be called transparently. But the spec doesn't require jdoPostLoad to be called if only fetch group A is active. My understanding of the spec is that this is controled by attribute post-load of element fetch-group. That's why I set it to true in my example below. There might be a typo related to fetch groups in chapter 12.7.2, the last sentence of the first paragraph: The callback will be called if an instance is loaded when any fetch group is active that contains the fetch-group set to true. Shouldn't it say ... that contains the post-load set to true. ? A better test might be to define the default fetch group explicitly as not having the fields, and define fetch group A as having the fields. Then you can have the default fetch group (not fetch any fields) invoke jdoPostLoad, but test that fetch group A fields have been loaded. I agree that a default fetch group having no fields is better than removing the default fetch group from the query fetch plan. Regards, Michael Craig On Oct 20, 2005, at 7:41 AM, Michael Watzek wrote: Hi, assertion A14.6-21 specifies: This method retrieves the fetch plan associated with the Query. It always returns the identical instance for the same Query instance. Any change made to the fetch plan affects subsequent query execution. I wonder, how the second part of this assertion can be tested. Does the following idea make sense: A class PC defines a fetch group A with post-load true. Class PC defines a postLoad callback which sets a transient field for each persistent field. The test case creates a query instance having candidate class PC. Afterwards, it retrieves the fetch plan, removes the default fetch group and adds fetch group A. Then, it executes the query. Finally, the test case checks for each returned query instance, if the transient fields which correspond with persistent fields of fetch group A have the right values. Would this work, or would the persistent field access in postLoad retrieve values from the database for non-loaded fields? Regards, Michael -- --- Michael Watzek [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ --- -- --- Michael Watzek [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ ---
JDO 2 TCK - Metadata of org.apache.jdo.tck.pc fieldtypes.TypeCollections.jdo possible incorrect
Hy ! We had a look on the JDO TCK 2.0 Tests. It looks like the JDO metadata for the non Map Collection Classes isn't correct aswell. For Example: VectorCollections.jdo has defined: field name=VectorOfObject0 collection element-type=org.apache.jdo.tck.pc.fieldtypes.SimpleClass /collection /field or field name=VectorOfSimpleInterface6 collection element-type=org.apache.jdo.tck.pc.fieldtypes.SimpleClass /collection /field but shall this not be java.lang.Object and org.apache.jdo.tck.pc.fieldtypes.SimpleInterface !? mfg Christian
[jira] Assigned: (JDO-98) TestArrayCollections: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this
[ http://issues.apache.org/jira/browse/JDO-98?page=all ] Andy Jefferson reassigned JDO-98: - Assign To: Michelle Caisse (was: Andy Jefferson) With JPOX latest build this now fails with test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)javax.jdo.JDOUserException: Field org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1 i s declared as a reference type (interface/Object) but no implementation classes of class java.lang.Object have been found! at org.jpox.store.rdbms.table.ColumnCreator.getImplementationNamesForReferenceField(ColumnCreator.java:244) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForReferenceField(ColumnCreator.java:310) at org.jpox.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:399) at org.jpox.store.rdbms.table.ColumnCreator.createColumns(ColumnCreator.java:94) consequently the MetaData needs updates so that implementations can map it. TestArrayCollections: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this -- Key: JDO-98 URL: http://issues.apache.org/jira/browse/JDO-98 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assignee: Michelle Caisse test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)org.jpox.metadata.InvalidMetaDataException: Field ArrayOfBigDecimal13 in class ArrayCollections has been defined with elements that arent embedded. JPOX doesnt support this - the elements must be embedded. at org.jpox.metadata.ArrayMetaData.populate(ArrayMetaData.java:106) at org.jpox.metadata.FieldMetaData.populate(FieldMetaData.java:662) at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:697) at org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:635) at org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:399) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:308) at org.jpox.AbstractPersistenceManager.hasMetaDataForPersistenceCapableClass(AbstractPersistenceManager.java:381) at org.jpox.AbstractPersistenceManager.assertPersistenceCapable(AbstractPersistenceManager.java:412) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:950) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1048) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:95) at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:197) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
