Attendees: Michael Bouschen, Craig Russell NOTE: There will be no meeting next week. The next meeting will be April 17.
Agenda: 1. JDO 3.1 released via Apache, announced to mail lists. Still to do: release as Maintenance Release 5 of JSR 243. Need to go through change lists in JIRA for 3.1 RC1 and 3.2 to prepare JCP Change Log. 2. JIRA "Make PersistenceManager support AutoCloseable (JDK1.7+)" https://issues.apache.org/jira/browse/JDO-735 Query should support AutoCloseable, too. Need tck tests. Looks good. 3. JIRA "Ability to save a (created) query as a named query for later use": https://issues.apache.org/jira/browse/JDO-734 Patch with API changes provided by Andy. Also need tck tests. Looks like the security configurations are a bit out of date. 4. JDO Next Andy proposes calling the next release JDO 4.0. Any other opinions? Andy has proposed a list of items to be included. > 1. The query API is dated, requiring casting of results to the required type. > Let's make use of generics etc and remove the pain. This will mean changing > the API so that the resultClass (and possibly more) will need passing into > the > execute() method(s). Could also specify parameters via setter rather than > just > on the execute. See 2 below also. Need a JIRA > > 2. Having a typesafe refactor friendly way of generating JDOQL queries is > required (as a complement to the current String-based approach). This has > already been proposed and worked through in JDO-652. The execution of this > should be aligned/integrated with 1). above. > > 3. Further to 1). above it would be nice to redesign the Query class to have > the setter methods as FLUENT, so a user could do > Query q = > pm.newQuery(Person.class).filter("firstName.startsWith('F')").orderBy("firstName"); > We could just add a subset of the setters as methods here without "set" so as > to align further with the typesafe variant in 2). Discuss, it's an idea. Need a JIRA > > 4. Ability to save a created query as a named query JDO-734 > > 5. Remove (long) deprecated methods from PersistenceManager JDO-687 > > 6. Standardise type converters JDO-709 > > 7. Make PersistenceManager support AutoCloseable JDO-735 > > 8. JDOQL BULK UPDATE/DELETE JDO-617 > > There are likely other things that could go in, but I'd rather get > "something" > than wait 3 years for all wish list items. Why not ask users? > > Many of these are already present in DataNucleus, so waiting for the RI > shouldn't be a hold-up. > > Bearing in mind the discussion around JDK level, and around the scope of > changes above, I'd recommend that JDK1.7 be used from JDO next onwards, and > the next version be called JDO 4.0 (since the Query API will be largely > rewritten - though (hopefully) retaining backwards compatibility). 5. Other issues Action Items from weeks past: [Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL datastores": https://issues.apache.org/jira/browse/JDO-651? [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-712 [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-625 [Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as persistent field types [Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about JDOHelper methods. In process. Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
