GAE: How to Match Object Oriented Projects Effectively in the Appengine Data Warehouse

Question

Suppose I have the following model of an object with me (you can change it the way you like, my interest is only effectively displayed),

public class Product{ private String someAttribute; //... } // A Seller who has a lot of products to sell, More than one Seller can sell the same Product public class Seller{ private List<Product> products; //... } public class Offer{ // who is offering private Seller seller; // multiple products can make an offer private List<Product> products; // pricing related private Price price; //... } 

I want to write a web application that will execute, read / write / search on these objects and assume that the entry point can be any of them.

Below are my inquiries,

• What is the design template that I will use? Am I guessing some kind of adapter pattern?

• When storing Seller’s objects, should I store links to Product objects as well? or just keys? I mean, should I convert the Merchant class to the following,

  public class Seller {private Product ListKeys; }

• If I want to write a scalable and supported application, I think that there should be a good design of my application in a multi-level architecture. Is there any example for this or an already used template? e.g. Some JSP → Service → DAO → dataStore? Examples would be really appreciated.

I also went through the AppEngineSDK for java, but did not use an example for it. help in answers or pointers is really appreciated.

Answer 1

With NoSQL databases (such as the GAE data warehouse), you should be thinking about a data access model, not a data storage model. That is, you should think about how you will access the data and how you organize the data so that access is most effective (= faster and cheaper).

Unfortunately, this often happens against the principles of OOP and the data warehouse “schema” (there is no Datastore schema, you understand that, right?) Does not fit very well with the Java OOP paradigm.

The way to achieve this goal is to de-normalize the data, which means that you write the data (as much as possible) in one large record, which also means that the data is redundant.

Now, since you cannot put all the data in one record, you need to make several concessions. To do this, you must decide:

• What data will be read more?
• What data will be more changed?

From your model, I would suggest that the Product and the Seller will not change much, but the proposal will often be created, right? Try to design so that you minimize the number of read / write operations - start with the data that is most used and organize the circuit so that you receive / set most of the data with a minimum number of read / write operations.

Trying to answer your questions:

• Just create your service level where you perform the main CRUD functions (add / update / delete / hire Seller / Product / etc) and higher level business functions (create an Offer for the Seller with Products, etc.)., DAO is PITA, so you should try to work with POJO as much as possible - use Objectify. In this case, you can end the adapter template.

• If you were referring to identifiers by links (long, long or string), then you should go with the keys: the keys are a combination of parent keys, type and identifier. Keys are guaranteed to be unique, but identifiers are not (they are unique only if you are not using Entity groups). In addition, with objectification, keys are type safe, but identifiers are not.

• As described in 1, a layered approach is the way to go. However, try to avoid DAOs - they require a lot of manual work and as such are a source of errors.

Answer 2

I would look at objectification: http://code.google.com/p/objectify-appengine/

In general, the rule of thumb with appengine data access is to avoid as many “connections” as possible. Retrieving large (even massive) datasets from a single table is very cheap in appengine, but retrieving from many smaller related data sources is very expensive. Thus, in your example, you would like to consider storing products in the form of built-in collections in the sellers table, if you can avoid this.

NTN

Rick