JDO TCK Conference Call Friday, Mar 30, 9 am Pacific Time
Hi, We will have our regular meeting Friday, April 6 at 9 am Pacific Time to discuss JDO TCK issues and status. Dial-in numbers are: US Toll free: 866 682-4770 Germany Frankfurt 06916106 Germany Toll free: 08006648515 (Other countries by request) To place the call: 1. Call the toll free number. 2. Enter the conference number 939-3689# 3. Enter the security code # Agenda: 1. log4j class loader, no enhancer log output with maven 2: https://issues.apache.org/jira/browse/JDO-706? 2. API build failure when using JDK 1.7. 3. SignatureTest failure for method Discriminator.discriminatorColumnName(), patch available for review: https://issues.apache.org/jira/browse/JDO-713 4. What's needed to release 3.1? Go to https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10630, click Issues in the menu on the left and then click JDO 3 maintenance release 1 (3.1) under Unresolved: By Version News on License for FrameMaker? 5. Other issues Action Items from weeks past: [April 8 2011] AI Craig comment on https://issues.apache.org/jira/browse/JDO-617 re the utility of the update operator. [Sep 23 2011] AI Michael document when changing dependencies (to DataNucleus) it's necessary to rebuild the exectck project before running tck. -- *Michael Bouschen* *Prokurist* akquinet tech@spree GmbH Bülowstr. 66, D-10783 Berlin Fon: +49 30 235 520-33 Fax: +49 30 217 520-12 Email: michael.bousc...@akquinet.de Web: www.akquinet.de http://www.akquinet.de akquinet tech@spree GmbH, Berlin Geschäftsführung: Martin Weber, Dr. Torsten Fink Amtsgericht Berlin-Charlottenburg HRB 86780 B USt.-Id. Nr.: DE 225 964 680
[jira] [Updated] (JDO-706) No enhancer log output with maven 2
[
https://issues.apache.org/jira/browse/JDO-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-706:
-
Fix Version/s: JDO 3 maintenance release 1 (3.1)
No enhancer log output with maven 2
---
Key: JDO-706
URL: https://issues.apache.org/jira/browse/JDO-706
Project: JDO
Issue Type: Bug
Components: tck
Affects Versions: JDO 3 maintenance release 1 (3.1)
Reporter: Michelle Caisse
Assignee: Michelle Caisse
Fix For: JDO 3 maintenance release 1 (3.1)
Attachments: jdo706.patch, jdo706.patch
No log output for enhancement is produced. The following warnings are issued:
[INFO] [jdo-exectck:enhance {execution: default-cli}]
log4j:WARN No appenders could be found for logger (DataNucleus.Enhancer).
log4j:WARN Please initialize the log4j system properly.
Enhancing classes for identity type datastoreidentity
The classpath available to the enhancer does not provide access to the log
properties file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Minutes: JDO TCK Conference Call Friday, April 6, 9 am Pacific Time
Attendees: Michael Bouschen, Matthew Adams, Michelle Caisse, Craig Russell Agenda: 1. log4j class loader, no enhancer log output with maven 2: https://issues.apache.org/jira/browse/JDO-706? There are several bugs when the tck is run. May be a class path or class loader problem. Can anyone else apply the patch and see what happens? The tck without the patch runs but runonce fails. 2. API build failure when using JDK 1.7. The compiler complains about naked template classes, e.g. Class? in JDOHelper. NOTE: The JDK 1.7 compiler has changed the stack frame layout. There will be real work to upgrade to 1.7 for enhancement. 3. SignatureTest failure for method Discriminator.discriminatorColumnName(), patch available for review: https://issues.apache.org/jira/browse/JDO-713 Patch looks good. Note that the signature checker validates that the default value for the discriminator is a discriminator annotation, but does not validate that the value of the discriminator has the default values. 4. What's needed to release 3.1? Go to https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10630 , click Issues in the menu on the left and then click JDO 3 maintenance release 1 (3.1) under Unresolved: By Version News on License for FrameMaker? No reply on the FrameMaker license. AI Craig try with another Adobe person. 5. Other issues Message from Henk Penning re bad signature in distribution. The issue was a bad KEYS.asc which is not a file that is needed anyway. The assumption is that the file had not been updated when the KEYS file was updated. The KEYS.asc file needs to be removed. AI volunteer remove the KEYS.asc file from where Henk moved it. [April 8 2011] AI Craig comment on https://issues.apache.org/jira/browse/JDO-617 re the utility of the update operator. Really? Is Craig going to do this? Action Items from weeks past: [April 8 2011] AI Craig comment on https://issues.apache.org/jira/browse/JDO-617 re the utility of the update operator. [Sep 23 2011] AI Michael document when changing dependencies (to DataNucleus) it's necessary to rebuild the exectck project before running tck. Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
[jira] [Commented] (JDO-617) JDOQL : Bulk Update and Delete Operations
[ https://issues.apache.org/jira/browse/JDO-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248893#comment-13248893 ] Craig L Russell commented on JDO-617: - I don't see the value in adding update by query to JDO, either in the query language or in the typesafe query methods. What we have defined already is using a query language to select a number of items to operate on (either read into memory or delete). Once you have the list of items, you iterate the list and perform some algorithm on the items using the native methods of the memory language, Java. Any changes will be reflected in the datastore if you commit the transaction. In contrast, specifying a Java algorithm to execute on all selected items from the datastore is fraught. Simply providing a constant new value for selected fields doesn't seem very useful. There are ways of specifying a Java algorithm to operate on some items, and passing the algorithm to the query method. For example, passing a function object (Runnable) to the query, and expecting the function object to be applied to each item in the result. The implementation would need to read the byte codes of the function object to figure out exactly what the function was doing and try to apply that function to the datastore objects. But I suspect that even this small bit of functionality won't be worth the considerable effort to implement. Bottom line, while I appreciate that there are many places where there is a natural mapping between a subset of Java that is useful to filter objects from a datastore and the corresponding datastore language, update is not one of these places. JDOQL : Bulk Update and Delete Operations - Key: JDO-617 URL: https://issues.apache.org/jira/browse/JDO-617 Project: JDO Issue Type: New Feature Reporter: Eric SULTAN It would be usefull that the JDO Query Langage could do some UPDATE and DELETE on Persistent Object like this : UPDATE [candidate-class] SET item1=newValue, item2=newValue [WHERE filter] The new_value specified for an update operation must be compatible in type with the state-field to which it is assigned. Bulk Update must modify the value of the version column and refresh Level1 and Level2 cache. DELETE FROM [candidate-class] [WHERE filter] By default Bulk Delete is appy on the specified class and its subclasses and doesn't do cascade delete. A keyword like CASCADE must be set if we want to does a cascade delete : DELETE CASCADE FROM [candidate-class] [WHERE filter] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JDO-713) SignatureTest failure for method Discriminator.discriminatorColumnName()
[ https://issues.apache.org/jira/browse/JDO-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen resolved JDO-713. -- Resolution: Fixed Checked in the patch (see revision 1310602). SignatureTest failure for method Discriminator.discriminatorColumnName() Key: JDO-713 URL: https://issues.apache.org/jira/browse/JDO-713 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3 maintenance release 1 (3.1) Reporter: Michael Bouschen Assignee: Michael Bouschen Fix For: JDO 3 maintenance release 1 (3.1) Attachments: JDO-713.patch JDO-702 added discriminatorColumnName to the Embedded annotation. This needs to be added to the signature file, currently the SignatureTest (configuration runone.conf) fails: found:public abstract javax.jdo.annotations.Discriminator discriminatorColumnName() default @javax.jdo.annotations.Discriminator(customStrategy=, indexed=, columns=[], column=, value=, strategy=UNSPECIFIED) Plase note, this requires changing the parser used by the SignareTest, because the class is not prepared to deal with using an annotation in the default clause: Discriminator discriminatorColumnName() default @Discriminator; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
