We are planning to use Spring Roo to generate GWT artifacts, would it be possible to use our RDBMS database or should the application rely on the app engine datastore if we eventually deploy the application on google app engine.
A:
you will use jpa over your database and when moving to app engine you just need to change the persistence setup to google_app_engine. with roo it's a one liner.
Ben
2010-07-04 12:58:41
Found the [blog post](http://blog.springsource.com/2010/06/02/using-springsource-tool-suite-2-3-3-m1-with-roo-and-gwt/) I recently read.
Ben
2010-07-04 13:03:57
If its just a one liner change, it would be a huge advantage for us.
2010-07-04 13:06:38
The following line is mentioned, but it doesn't mention anything about App Engine using a JPA provider. Can you clarify?First you probably want to switch from the in-memory Hypersonic database used by the sample application to Google's Datastore based on BigTable. To do this launch the Roo shell from the command line and execute the following command: "persistence setup –database GOOGLE_APP_ENGINE –provider DATANUCLEUS".
2010-07-04 13:16:22
When you start a roo project you will specify the persistance mechanism you would like to use. You can you any database and one of a few providers (like hibernate).Afterwards you could change this setup.DataNucleus is the jpa provider for BigTable.
Ben
2010-07-04 13:35:33
This will clearly NOT be as simple (since Google's datastore is not a relational database).
Pascal Thivent
2010-07-04 20:13:46
I agree, had the same concern regarding using a JPA data model. So if it really means that Spring Roo will provide some generated classes to start with, I could as well start with what is being offered by GAE itself or wrappers like Objectify.
2010-07-05 03:50:53
+3
A:
It may be possible to swap out your datastore with a single line, but I'm not sure it's the best idea to do so. The App Engine datastore is not a relational database, and in fact is very different from one.
When you design your schema, you should either do it thinking in a relational mindset, or in a non-relational one, and even if it's a one-liner to change your datastore provider, it definitely won't be a one-liner to redesign your schema.
Trying to shoehorn your relational schema onto a non-relational datastore will be hugely inefficient, at best. And vice versa.
So my advice is to either design your schema based on the knowledge that it will be in a non-relational datastore like App Engine's, or relationally, on some other datastore system.
Jason Hall
2010-07-04 19:53:07