Ah, well tagList is just the list of tags for that book, so its only going to hold between 0-4 tags. Having that listProperty with book at least makes filtering books by tag easy.
like 'gimmie all the books that are tagged 'sci-fi' and 'adventure' , sorted by 'number of reads'. That bit is a single query. On Jul 8, 3:56 am, Jeff Schwartz <[email protected]> wrote: > 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.
