Since I said that there were requests from users of what they would like in
JDO, here is a (incomplete) list of items that should be considered for JDO
"next".
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.
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.
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
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).
Regards
--
Andy
DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
