Hi Nick, my query uses zig-zag merge-join with an arbitrary length
of equality filters on a StringListProperty to get result sets, so I
can't use a composite index (unless the exploding index problem has
been solved or I've fundamentally misunderstood exploding index).
Also Nick, maybe you could
Julian, that is _exactlty_ what I was looking for. Counting up to a
future time to create descending values... It seems so obvious now!
It's a much better solution than the de-accumulator handler that I
wrote.
Thanks!
On Feb 14, 11:57 pm, Julian Namaro namarojul...@gmail.com wrote:
I am not
Why not just use regular timestamps, and sort descending?
-Nick
On Wed, Feb 16, 2011 at 1:42 AM, Joseph Letness joe.letn...@gmail.comwrote:
Julian, that is _exactlty_ what I was looking for. Counting up to a
future time to create descending values... It seems so obvious now!
It's a much
I am not sure about the mathematics of it, but intuitively there is no
perfect algorithm for constructing timestamps in a reverse
lexicographical ordering, because adding a character to a string will
always make it lexicographically superior.
But I noticed the mapreduce library just pick a
Hi Calvin and Robert, thanks for your replies. I should have been
more clear about what I am doing, here is some more info:
Calvin, thanks for the link to Ikai's blog post, I haven't seen that
one and it was very interesting.
Robert, here are specific answers to your questions:
Why do you say:
If your key name was the based off of datetime.utcnow().isoformat() you
could always get the last entity created by doing a query like this:
last_created = model.all().filter('__key__ ', db.Key.from_path('model',
datetime.utcnow().isoformat())).get()
and you could get the next newest by
