On Fri, May 1, 2009 at 7:24 AM, Morten Bek Ditlevsen <morten....@gmail.com> wrote: > > 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?
The autogenerated _set properties, as you mention below, simply return queries, so it's exactly the same as doing two queries. Whether that's acceptable is up to you. Personally, I would either use lists, or do a one-to-many with entities representing an occurrence of a word in a particular document. There's little real benefit in having abstract 'word' entities and a many-to-many. > > 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. Absolutely. Since you'll be doing one equality filter (for the word) and an inequality, that'll work fine. > > My question is: are there any restrictions/penalties for creating the *_set > queries? Nope, it's all just syntactic sugar. > > > Thanks for your help! > Sincerely, > /morten > > > > > -- Nick Johnson <nickjohn...@google.com> Bigtable SRE [http://labs.google.com/papers/bigtable.html] Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 Gordon House, Barrow Street, Dublin 4, Ireland --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
