Hey Tom,
Yup, the solution I suggested will touch multiple entity groups.
That means the best we can do is probably eventual consistency, but it
can still be really fast.
Check out transactional tasks, if you've got low update rates or you
don't expect a great deal of contention, you could si
My understanding on app engine index for our case is that we could build an
index as
{ width (ascend), height(ascend), key }
so we can query GQL like : width=5, height>0, width=5, height<15. So all the
information we need is ready for us to retrieve efficiently.
--
You received this message b
Carter's method is good for slow update and I will definitely use it.
I do need an "interactive solution" in the mean time. Robert, your method
will be touching two entity groups, so there might be inconsistent results
when one of the transactions fails.
I really hope we can query/count the ind
If you need the queries to run 'interactively,' you might want to
implement 'custom indexes' to keep track of all heights for width 5.
I do this in some apps, it makes 'queries' super fast at the expense
of increased write cost. In this case you could create a model who's
key_name will be the widt
http://code.google.com/p/appengine-mapreduce/ is a good way - if by
"efficient" you mean efficiently performed on app engine.
On Sat, Aug 13, 2011 at 1:29 PM, Tom Fishman wrote:
> Say there are the following entities:
>
> {ID:1, width: 5, height: 11, ... },
> {ID:2, width: 5, height: 12, ... }
Say there are the following entities:
{ID:1, width: 5, height: 11, ... },
{ID:2, width: 5, height: 12, ... },
{ID:3, width: 5, height: 12, ... },
{ID:4, width: 6, height: 13, ... },
{ID:5, width: 5, height: 12, ... },
{ID:6, width: 5, height: 13, ... },
{ID:7, width: 5, height: 12, ... },
.
