Hi Nick, > > > 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).
Ah, I see! Thanks, that's just great! I must say that app engine programming is by far the most fun I've had in programming for a long time - the possibilities and constraints really have to make you think differently when solving problems! > > > 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. > Great! Sounds like both solutions would be interesting to try out. I have a related question about a different way of solving part of this problem: Let's imagine that I have an entity that just contains a single word. Then I have a 'many-to-many' entity that references both the word-entity and my existing 'user profile' entity. Is the query for a word, followed by a subsequent .manytomany_set reference query expensive to do, or is that completely feasible? What if I extended the many-to-many entity with (say) one geobox string? I understand that the _set operator returns me a query. Then I could run a filter on that query before fetching. My question is: are there any restrictions/penalties for creating the *_set queries? Thanks for your help! Sincerely, /morten --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
