I wouldn't put the list attribute in your book class due to serialization issues and exploding indexes. I'd put the list in a sub class of book and query the subclass to return a list of entity keys on a match. As child keys contain parent keys as well, I'd use the list of keys returned to grab the actual book entities. You can refine this as much as you like.
Jeff On Wed, Jul 7, 2010 at 1:58 AM, stefoid <[email protected]> wrote: > Hi I think I have a fair handle on how Datastore works, but I need to > check, and I need some help with a design > > lets say I have: > a very large list of BOOKS > the BOOKS are tagged- "adventure+romance", "historical+drama", > "animation+sci-fi+comedy", etc... > and I have a very large list of USERS. > USERS can read a very large number of BOOKS > And I, as a USER, can have a very large number of USERS who are my > friend. > > What I want , in english, is > ; Return a list of all the BOOKS tagged with "sci-fi" and "romance" > that have been read by USERS who are my friend, sorted by Most > Frequently Read. > > Now, I know I can model tags with a ListProperty, so that filtering is > easy = "WHERE tag AND tag AND tag..." > And I know that I can sort Books by Most Frequently Read quite easily > > But due to the large number of BOOKS that could be read by a USER, > and the large number of USERS who could be my friend, I cant > practically model BOOKS READ BY USERS and USERS WHO ARE MY FRIEND as > ListProperties... > > ...Because I would blow the 5000 index limit per entity, because each > value of ListPropery generates its own index entry. Is that correct? > > I cant find a way to handle this without resorting to filtering in > memory. Am I dumb, or is that just the way it is? > > My solution is: > > BOOK: > numerOfReads > TagList > otherStuff > > > Then I look up a relationship entity to find out everyone who is a > FRIEND of mine. > FRIENDS: > userKey > friendKey > > Then I look up a relationship entity to find out which BOOKS that > USERS have read > BOOKSREAD: > userKey > bookKey > TagList > numberOfReads > > So first I pull into memory the list of my particular friendKeys from > the FRIENDS table. > > Then I churn through the table of BOOKSREAD, using the duplicated > properties TagList and numberOfReads to filter on tags and sort > according to number of reads. > > I then filter this list of BOOKS *in memory* by the friendKeys I > have. Ill need some sort of algorithm to keep pulling chunks of BOOKS > from the database until I have a nice page of books my friends have > read (20 books displayed per page) to pass to the GUI. > > ???? > > -- > 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]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- -- Jeff -- 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.
