Hi all

I'm testing the waters with App Engine (Java) and wondered if anyone
could help with my understanding of the "app engine way of doing
things" with regards to queries and efficiency.

Essentially my question is this: given that AE charges for each query
made, and not for CPU usage, isn't it better to serialize and pack
your data in to fewer, larger entities than to follow the standard
data modeling approach of giving each business object it's own table
row?

Lets say I have a website with 100 pages. For each page served, I need
to render a navigation tree of links requiring page names, their URLs,
and their position in the tree. So say I request a level 3 page in the
tree like "Page 1 > Page 1.2 > Page 1.2.3", I need all names and urls
for all pages at levels 1,2 and 3.

A conventional approach would be to have a Page table, with properties
for "name" and "path" (containing the position of the page in the
tree). When a page is requested, I then need to look it up, find out
it's path, and then request all other pages that will be shown in the
navigation according to that path.

Translating this to app engine, I would need to run a query like
"path" IN [level_1_path, level_2_path, level_3_path], which I have
learned in reality boils down to a separate query for each tree level.

(side note: I know that using AE's built in ancestor hierchary makes
queries faster, but Entities can't be moved after being assigned a
parent, and this is a feature i need. So I believe I need to manage by
own tree the "path" property, which would look something like "1.2.3")

So the conventional wisdom of building a single big query to do
everything you want being the most efficient thing you can do doesn't
seem to apply.

Alternative approach: have a single "site" Entity with a property in
which I would store a big HashMap containing all the essential page
information. This can be serialized and compressed and stored as a
String. Each request then only needs to load this one Entity for the
purpose of building the nav.

In the conventional setup, this wouldn't be as efficient because it
would probably be faster to run the big query than to load and
unserialize the hash map data for every request. But since I'm being
billed for queries and not CPU usage on AE, is this not the better
approach?

Or can anyone suggest a better one?

Many thanks for your time

Adam

--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@xxxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to
google-appengine+unsubscribe@xxxxxxxxxxxxxxxxx
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.