SimpleDS provides a simple persistence framework for Google AppEngine that gets as little in the way as possible. It is barely a wrapper around Datastore APIs, providing mapping between Entity and Java classes.

AppEngine provides a really powerful service to store persistent data in the cloud, but the provided API to handle it is cumbersome:

• The Datastore API is too much low-level, providing bare persistence of Map-style structures.
• The JDO and JPA APIs are too complex for even the simplest tasks, and hurt performance by adding lots of extra checks designed for relational databases.

This release includes some great new features:

• Level 1 and 2 cache.
• Background tasks to override the 30 seconds limit in AppEngine.
• Functions, a feature that can be combined with caching to get a performance boost by converting n+1 queries into two queries.

Other minor features have also been implemented, such as:

• Cursor support.
• Newer operators such as

Would you share with us the evidence that JPA / JDO is too complex and too slow.

JDO designed for RDBMS? I didn't know that.

JDO implementations are available for non-SQL datastores (this has even been used as an argument against JDO since its inception).

Best regards, Eric.

Go to the java app engine mailing list and look at all of the people flailing with jdo and jpa.

There are many many things that jdo and jpa provide that you can't do with the App Engine data store, and which are either aren't documented or, at best, not well documented.

Go to the java app engine mailing list and look at all of the people flailing with jdo and jpa.

The point was JDO was not designed for RDBMS, not even close. JPA was, definitely. Whether people are "flailing" is a separate issue; one related to the implementation being used.

Whether JDO (or JPA) provides things that are not necessarily required to use a NoSQL datastore is a different issue (and all that is required there are clear docs to say feature X, or feature Y is not suitable for this datastore - we do the same thing with all other datastores supported), and that doesn't prohibit use of those APIs. The APIs do not contain anything "difficult"; I've challenged people in the past to provide examples, and please stick to the "API" itself, and not to how it was implemented; which part is "too difficult" ? For referene the API is listed here

http://db.apache.org/jdo/jdo_v_jpa_api.html

Perhaps reading

http://datanucleus.blogspot.com/2010/01/gaej-and-jdojpa.html

would also help.

Developing alternative solutions for persistence is a great thing, and SimpleDS is a good step ... these are the things that provoke people to think, and for the specifications to react. JDO itself actually has a JIRA issue to analyse where it can be better adapted to "NoSQL" datastores (if any changes are indeed necessary).

I love GWT and Google App engine. I've been developing a few different sites with it. There are a few limitations in the JPA implementation that really create roadblocks. There are detours around them, but they're just not elegant, nor do they instill confidence. Here's a description of some of the unsupported JPA features in the Google App Engine that tend to bring RDBMS applications to a grinding hault:

http://code.google.com/appengine/docs/java/datastore/usingjpa.html

Unsupported Features of JPA

The following features of the JPA interface are not supported by the App Engine implementation:

• Owned many-to-many relationships, and unowned relationships. You can implement unowned relationships using explicit Key values, though type checking is not enforced in the API.
• "Join" queries. You cannot use a field of a child entity in a filter when performing a query on the parent kind. Note that you can test the parent's relationship field directly in query using a key.
• Aggregation queries (group by, having, sum, avg, max, min)
• Polymorphic queries. You cannot perform a query of a class to get instances of a subclass. Each class is represented by a separate entity kind in the datastore.

The point was JDO was not designed for RDBMS, not even close. JPA was, definitely. Whether people are "flailing" is a separate issue; one related to the implementation being used.

Hi,  I am SimpleDS main developer. I did not mean to say that JDO was designed with RDBMS in mind, just that working with the current state of JDO/JPA in AppEngine is way too complex and that drove us to develop our own solution.

The APIs do not contain anything "difficult"; I've challenged people in the past to provide examples, and please stick to the "API" itself, and not to how it was implemented; which part is "too difficult" ?

I agree that some of the problems may be caused by the implementation, even if there are also issues that fall out of the JDO standard (e.g. supporting more than one active transaction open at the same time). It's great to hear that JDO is adapting to these.