Which is percisely what is not supported. Imagine for a minute that the datastore supported it, it would work quite well with say 100 records. Even 1000 records might work at a push, but once you start getting to about 10,000 the datastore would almost certainly start to cry, and soon fall apart.
Remember to calculate the distance the datastore has to run that calculation on EVERY row, and the datastore is a distributed system. To load the two properties for the calculation has to fetch the whole row from bigtable - this has to be transfered to somewhere central to do the calculations, and to a *single* place to do the sorting. That is a LOT of information transfer for potentially a small amount of actual data. A traditional SQL database makes this sort of query almost trvial, and again for small databases can work quite well - mainly because they have the data stored squentially in once place so it can load it quickly. But start getting into the thousend of results, and the performance is going to suck. The datastore maintains reasonable performance simply because it makes heavy use of indexes, probably every query uses an index. A full table scan even uses an index. But this sort of query cant make use of an index in the traditional sense. If the number of results is less than 1000 (either because that is all you got, or you filtered to that number) then you can do the calculation and sorting in the application. But in practice, probably 100-200 is a maximum - so you need to aggressively filter. Should of pointed you at it before but see: http://code.google.com/p/geodatastore/ that shows some of the practical implementations. But it quickly gets beyond trivial, which is why I lost interest in the project. You should also star http://code.google.com/p/googleappengine/issues/detail?id=105 to encourage Google to add a Spatial index type for GeoPt. (Google have obviouslly figured it out internally with Google Base and Google Maps (which may use Base) ) 2009/1/16 arnie <[email protected]>: > > I can limit records returned through query to say 15 or 20 or 25 rows > but my problem is that the calculation that i needs to do on returned > records needs results with distance in ascending order. It may be that > in first 25 rows, there may be distances that are greater than the > distances calculated in subsequent fetching. That's why I am looking > for a way to do calculatin in query and then order by ASC. This is > happening because the table only contains info about businesses like > name, physical address, latitude, longitude and using the latitude and > longitude as provided in request we haave to calculate distance in > miles and then sort the results in ascending order of distances > Thanks > > > -- Barry - www.nearby.org.uk - www.geograph.org.uk - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
