GAE : How to map object oriented designs into Appengine datastore efficiently

Question

Lets assume that I have the following object Model with me (you are free to change it in a way you like, my interest is only mapping efficiently),

public class P         


        

Answer 1

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

In general the rule of thumb with data access in appengine is to avoid as many "joins" as possible. Fetching large (even massive) datasets from a single table is very cheap in appengine, but fetching from many smaller related sources of data is very expensive. So in your example you would want to consider storing products as embedded collections in the seller table if you can get away with doing that.

HTH

Rick

Answer 2

With NoSQL databases (such as GAE Datastore) you should be thinking in terms of data access model, not data storage model. I.e. you should be thinking how you will be accessing data and how you will organize data so that access is most efficient (= faster and cheaper).

Unfortunately this often goes against OOP principles and Datastore "schema" (there is no Datastore schema, you realize that, don't you?) does not fit nicely into Java OOP paradigm.

A way to achieve this is to de-normalize data, meaning that you write data (as much as possible) in one big record, which also means that data is redundant.

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

1. Which data will be read most?
2. Which data will be changed most?

From your model I'd guess that Product & Seller would not change much, but Offer will be often created, right? Try to design so that you minimize number of reads/writes - start with data that is used most and organise schema so that you get/put most of data with minimum number of reads/writes.

Trying to answer your questions:

1. Just create your Service layer, where you perform basic CRUD functions (add/update/delete/find Seller/Product/etc) and higher-level business functions (create Offer for Seller with Products, etc..). DAOs are PITA, so you should try to work with POJOs as much as possible - use Objectify. In this case you could do away with Adapter pattern.

2. If by references you meant IDs (long, Long or String) then you should go with keys: keys are a combination of parent keys, kind and ID. Keys are guaranteed to be unique, while IDs are not (they are unique only if you are not using Entity Groups). Also, with objectify, keys are type-safe, while IDs are not.

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