Try to combine x and y into a granular z, which can be checked against. E.g. if for a geographic query you'd combine lat & long to get a hash with a reasonable granularity (whatever suits your application). Pre-calculate those and save them to the store. You lose out the fine-grained inequality tests, but you gain a lot of speed, which reduces your read costs hugely.
Richard On May 1, 9:30 am, romesh soni <[email protected]> wrote: > Hi Tristan, > The solution you provided is the best one among of those which I have found > so far. But this is not what I was looking for, my database is quite large > and its will grow continuously to millions of records in time. But there > will be only 1 matching record for my filter (x<=y and y>=z) If I try your > suggested approach, then I will have to scan all records in loop.(1000 > limitation) > > On Fri, Apr 30, 2010 at 6:58 PM, Romesh <[email protected]> wrote: > > I have been trying to find a workaround for this limitation and spent > > 2 days and read almost all blogs, discussion > > groups....................., but can not find a solution to it. Has > > any one able to find a way to handle this limitation? (The List > > property solution doesn't work.) > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" 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 > athttp://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
