On Nov 3, 11:35 pm, Eli <[email protected]> wrote:
>
> (This is just the first usage example that comes to mind. This row
> naming method could be used for all sorts of set intersection stuff,
> and would cut down on insert times due to the fact that it should
> partition out the indexes when dealing with humongous datasets).
I don't think what your proposing is a physical optimisation because
indexes are not discrete objects as they are in a traditional
relational database:
http://code.google.com/appengine/articles/index_building.html#Index%20Layout
Forgetting about physical optimisation and thinking only about
querying slices of the data, how about something like this:
class Stats(db.Model):
number = db.IntegerProperty()
date = db.DateTimeProperty()
dimensions = db.StringListProperty()
e = Stats(number=42,
date=datetime.datetime('1605-11-05'),
dimensions=['1600', 'November', 'Q4', 'd5', 'Saturday'])
Then you could query by date, as in your example, by simply querying
against the date property. But you could also query for all numbers
for any Saturday in the 4th quarter of any year:
q4Saturdays = Stats.all().filter('dimensions =', 'Q4').filter
('dimensions =', 'Saturday')
> Anyway, this was just a side thought I had while wondering what the
> point of Expando was.. since it's so unstructured.. I couldn't imagine
> why someone would want such an undependable datasource..
http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---
