As changes are requested by the community (for example, on mailing lists or JIRA) they will be added to the PROPOSED list here. When they are implemented, they are moved to ACCEPTED. When a maintenance release is being shipped, unimplemented items will be moved to the DEFERRED list. When a maintenance release is being planned, items from the DEFERRED list are reviewed.
Option 1 : Simple PMF property "javax.jdo.option.queryTimeout" to specify the number of millisecs (or secs) before any query is timed out. Throw a QueryTimeoutException (extends JDOException) when the timeout happens
Option 2 : as Option1, plus setTimeout() on Query to define it on a per query basis.
Option 3 : as Option2, plus we add cancel() on Query so that users can cancel long running queries programmatically, throwing a QueryInterruptedException (extends JDOUserException). The cancel would apply to all currently running invoked queries from that Query instance.
<http://db.apache.org/jdo/api23/apidocs/javax/jdo/Query.html#executeWithMap%28java.util.Map%29>
IMHO this is a feature making the use of JDO with dynamic queries (and implicit parameter declarations) more complicated than necessary. It would be more developer-friendly, if it was legal to pass more parameters than the ones actually used, because they don't harm and it removes the need for additional tracking logic (which parameter is used, which one isn't).
I therefore recommend to relax the rule from exact match to "super-set", i.e. only these 2 requirements:
method executeWithMap(...).
executeWithMap(...).
For downward compatibility, I recommend introducing an option that can be passed to the PersistenceManagerFactory (in the properties). As a first idea, I recommend: javax.jdo.option.QueryParameterExactMatch (with values "true" and "false").
This request is to modify the JDO specification (and TCK & RI) so that it relaxes certain portions of the specification, perhaps in the form of profiles similar to JavaEE 6 profiles, to allow datastores that may not support queries in general, do not support the ACID requirements, or that support key-value-based storage mechanisms to be JDO-compliant. Additions to the specification may also be needed in order to directly address NoSQL-type datastores, in a manner similar to its treatment of relational persistence mechanisms. Additionally, this request would serve to better support persistence on micro platforms where consistency, queriability, etc, may not be supported.
String.charAt(int) String.startsWith(String, int) String.length() String.trim()
Enum.ordinal() Enum.toString()
The following are obviously deprecated in the JDK, but worth consideration Date.getHour() Date.getMinutes() Date.getSeconds() Date.getDay() Date.getMonth() Date.getYear()
We already have JDOHelper.getObjectId(Object), so why not add JDOHelper.getVersion(Object)
On a related topic JDO-633 has "List.get(int)".
Note that all of these are already implemented in the RI.
We already have Math.abs, Math.sqrt, so why not also have
Math.acos(number) Math.asin(number) Math.atan(number) Math.ceil(number) Math.cos(number) Math.exp(number) Math.floor(number) Math.log(number) Math.sin(number) Math.tan(number)
With spreadsheet documents, it is critical to be able to define which column number is used for a particular field. With other datastores it is also likely desirable.
To achieve this I propose adding an attribute to the XML <column> called "position". Similarly for the @Column annotation. This can take integer values with 0-origin.
Complications :
The reason for the splitted approach is that a standardization of the general model would benefit also other frameworks and could become a foundation for LINQ in Java.
The general part could be formed of the contents of the following Querydsl packages :
com.mysema.query com.mysema.query.types
com.mysema.query.types.custom com.mysema.query.types.expr
com.mysema.query.types.path com.mysema.query.types.query
The JDO specific elements could consist of the following elements :
com.mysema.query.jdoql.JDOQLSubQuery -> javax.jdo.query.SubQuery ?!? com.mysema.query.jdoql.JDOQLQuery \-> javax.jdo.query.Query ?!?
of course with some modifications and a standardization of the code generation (probably also via APT).
What do you think about this approach?
Are there any plans to add Query by Criteria to the JDO standard? I'm referring to a programmatic API to build queries, similar to what Hibernate already has and JPA is planning to add.
If not, does anyone know of another route to achieving this functionality? Are there any libraries that can be layered over JDO to get this? Should I write my own?
QueryDSL already does that for JDOQL http://source.mysema.com/display/querydsl/Querydsl I'm sure the guys who wrote it would love to hear feedback
A few years ago some of us remember dark clouds on JDO's horizon. Recently there were some of a different kind http://www.datanucleus.com/news/google_app_engine.html
are found here http://source.mysema.com/display/querydsl/JDOQL+Guide
Would be great if JDO supported streams, similar to OPENJPA-130