On Thu, Apr 30, 2009 at 3:06 PM, Morten Bek Ditlevsen <[email protected]> wrote: > Hi Nick, > > Thanks a bunch! I'm really amazed that I can just throw out a question like > this and have a googler reply within minutes! :-) > > >> > >> > The application is a location based dating service. Right now location >> > lookups are working ok, but I am wondering whether it is feasible to >> > have >> > location based lookups paired with text search at all - or if some of my >> > processing should be in python code instead of done through table >> > queries. >> >> I would suggest refactoring. You can make the inverted index for the >> text a separate entity, or you can do that for the geoboxes, or you >> can take a Hybrid approach: For example, you could have an entity that >> stores a top-level approximation of the user's location (eg, Country, >> State, or whatever is the highest level at which someone will query if >> they're specifying a geographical bound) in addition to the keywords >> in order to narrow the search down. > > Just to make sure I understand this right (well, rather - I don't think I > get it 100%): > > By the inverted index entity you mean a new entity kind where I store word > lists and then reference this entity from my 'user profile' entity?
Yes. The list of words used for fulltext indexing is called an 'inverted index'. > > This will allow me to create a query that fetches a list of entities for > which I can find the referring 'user profile' entities. > > But how can I combine that result with other queries? You need a (fairly simple) query planner, that can decide to either perform a text or bounding box query, then filter (in user code) the results for those that match the other filter. You decide which to pick based on which you think will have the fewest results (for example, a query for a small area will take preference over a search for the string 'friendly', whilst a search for the string 'solipsist' should probably be used instead of a query for all but the tiniest areas). > The same goes for the hybrid example. I see how this can be used to give me > a subset, but can that subset be queried any further? In that case, you can (hopefully) assume that the number of results for your keywords in your geographical area is small enough that you can filter them manually, without the need for explicit query planning. You can also use 2 or more levels of geographical nesting - just fewer than your main index, to keep the index entry count under control. -Nick Johnson --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
