Spring Data JDO request

[matthewadams]

JDO is largely a functional superset of JPA, encompassing not only relational databases, but also object databases and key/value stores.

As there is no subproject of Spring Data that addresses JDO, I would like to see a new subproject of Spring Data, "Spring Data JDO". I think it would be better to keep Spring Data JDO separate from JPA and the other subprojects, as JDO itself enables support for most if not all of the database types addressed by the other subprojects -- it has been since its inception database type agnostic.

The JDO implementations supported out of the box should include, at a minimum, DataNucleus, the reference implementation for JDO.

By creating such a subproject, all data stores supported by DataNucleus and any other JDO implementation can be supported. For a partial list of the database types and database vendors supported by DataNucleus, see
http://www.datanucleus.org/products/accessplatform/datastores.html

The code from Hades (http://redmine.synyx.org/projects/hades) could be fairly easily forked and modified to support JDO.

Thanks,
Matthew

[Marten Deinum]

Erhm... Isn't [url=http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/orm/jdo/package-summary.html]JDO supported by the spring framework itself? Is has the same level of support as Jdbc, Jpa or hibernate... So not sure what is missing there...

[matthewadams]

...Isn't...JDO supported by the spring framework itself?

JDO is supported by the Spring Framework itself. So is JPA. I would then ask the question, why Spring Data JPA? If I were to fathom my own answer, it would be that it adds value for many developers who need some CRUD code. I would still welcome your answer to that question, though.

Is has the same level of support as Jdbc, Jpa or hibernate... So not sure what is missing there...

While technically superior in my opinion, JDO support across the Spring portfolio has been waning in favor of the market's embracing of JPA, for whatever reason that happened (which is an entirely different discussion, BTW). Many Spring projects offer more (or exclusive) JPA support out of the box than they do JDO support: Spring Web Flow, Spring Roo, and now Spring Data. I'm sure there are others.

If you look at the subprojects of Spring Data for each of the different database types and products, and if you consider that each of those database types and products could be supported by JDO, then you'll see that JDO has always been the data access API that everyone has wanted for all these years: something that is database type-agnostic and places very few limitations on developers, certainly fewer than JPA does. Further, JDO enables features that are either brand new (collections of string and other basic types, mixed field- and property-based access, etc.) in JPA 2.0 or still nonexistent in JPA (fetch plans). I don't want to make this thread a how-JDO-is-better-than-JPA thread, but JDO also takes a decidedly different direction, again for the better IMHO, when it comes to querying: three forms of query (traditional API, single-string form, and a proposed fluent API that is very much worth looking at) and it cleanly separates projection (shape of query data) from criteria (the "filter" or "where" part) from fetch depth & breadth (the fetch plan). JPA requires the use of JPQL's JOIN syntax, unnecessarily complicating query design. There is also an issue, JDO-651, to ensure that JDO properly addresses support for NoSQL data stores -- chances are that it already does to a very large degree. In fact, DataNucleus already supports several NoSQL stores., including Amazon's S3, HBase, Google AppEngine for Java's BigTable, MongoDB, and Cassandra.

Why make all of these Spring Data subprojects when a single subproject, Spring Data JDO, could handle them all? Thanks to DataNucleus's plug-in architecture, any data store currently unsupported could have support added for much less development effort (that for the plug-in only), giving developers access to it with literally no code changes, only changes in metadata.

-matthew

[Mark Pollack]

Hi,

I am quite in favor of a 'Hades' like support project for basic CRUD with JDO as backend. I will open up a project for that with that as the initial goal - which parallels the JPA support. The Hades code base had started to be refactored to a database agnostic part (here) and then implementations for different nosql stores. Mongo support is the first, see here.

There is another mapping project, code named 'inconsequential' (here) that has a fair number of advanced features to it and is the basis behind the recent work in GORM to support NoSQL stores. This is the more advanced API will be pursuing to expose to Java developers (the underlying code is in Java, not groovy).

We did look into JDO as an approach but the consensus was not to pursue JDO implementations. It doesn't feel like a very good fit, expectations for a full implementation is what I think developers expect and it is hard to reach that level of compatibility, pass TCKs etc.

While the focus in this thread has been on mapping, a good deal of the work within the Spring Data project is on 'JdbcTemplate' like support for the various databses, so that one can directly interact with the full features set of each nosql database without consideration of abstractions across the different database. See the Redis and Riak releases for an example.

Cheers,
Mark

[matthewadams]

Hi,

I am quite in favor of a 'Hades' like support project for basic CRUD with JDO as backend. I will open up a project for that with that as the initial goal - which parallels the JPA support. The Hades code base had started to be refactored to a database agnostic part (here) and then implementations for different nosql stores. Mongo support is the first, see here.

Great!

We did look into JDO as an approach but the consensus was not to pursue JDO implementations. It doesn't feel like a very good fit, expectations for a full implementation is what I think developers expect

This, I understand. It would seem to be somewhat of a canonical layer (Spring Data) on top of another canonical layer (JDO).

and it is hard to reach that level of compatibility, pass TCKs etc.

I'm not sure I quite followed that last bit about the TCKs, etc.

While the focus in this thread has been on mapping, a good deal of the work within the Spring Data project is on 'JdbcTemplate' like support for the various databses, so that one can directly interact with the full features set of each nosql database without consideration of abstractions across the different database. See the Redis and Riak releases for an example.

Understood. At least with a JDO-based Hades-like set of CRUD features, folks can choose to stay at the JDO level, or drop down to the native level. One option there in addition to Spring Data is to leverage the fact that JDO gives a user access to the underlying connection. See JDOConnection. It would be interesting to see how Spring Data might be able to be used with the object returned by JDOConnection#getNativeConnection() to make dropping down more convenient for the user. IOW, to use the standard API's mechanism to get at the underlying connection, then use Spring Data Xxx along with that connection to make native access easier.

Thoughts?

-matthew

[matthewadams]

...I am quite in favor of a 'Hades' like support project for basic CRUD with JDO as backend. I will open up a project for that with that as the initial goal - which parallels the JPA support....
Cheers,
Mark

Hi Mark,

Have you begun this work? I noticed that Spring Data JPA 1.0.0.M1 was just announced. I didn't see a Spring Data JDO project in there yet.

-matthew

[andy]

We did look into JDO as an approach but the consensus was not to pursue JDO implementations. It doesn't feel like a very good fit, expectations for a full implementation is what I think developers expect and it is hard to reach that level of compatibility, pass TCKs etc.

Not sure what you mean by "not a very good fit" with respect to JDO and other datastores (e.g "NoSQL"). DataNucleus actually has pretty reasonable support for many other datastores using JDO (and JPA to a lesser extent) and there is (still) no obvious missing aspect of such datastores that is not handleable using JDO. Just take a look at the datastore features matrix for DataNucleus v3. In particular the plugins for HBase and MongoDB (which have had recent work) benefit from a very high level of JDO compatibility, and would get very close to any type of "compliance". More on that subject here. You cannot use Google's GAE/J DataNucleus plugin as the basis for any such judgement.

As Matthew says, having a Spring Data JDO it is a logical extension of the framework that Hades has for JPA and ought not to be so difficult to accomplish, so hope you go forward with that.

[Ross Attrill]

I have created a JIRA request for a Spring Data JDO module here:

https://jira.springsource.org/browse/DATACMNS-96