Eli, what I make out from your posts above is that I can go for either of them depending upon my requirement and can do a small application to test which suits my requirement best. Thanks a lot.
Jeff, from your posts I infer that it is better to go for a Join(Mapping) class then going for List. I will see the youtube video and try to understand what you are trying to convey. I also hope that I get to learn how are Lists stored in datastore. Jeff, as requested in my last post can you please put some light on your statement on counters you made in your post above, "As for counters, they would be implemented via a separate sub system as counters and memberships cannot be represented efficiently on the datastore using the same models. ". Thanks a lot. On Aug 25, 5:22 pm, Jeff Schwartz <[email protected]> wrote: > A key point to remember when modeling entities with list properties that are > to be used as indexes to other entities is to model them as children in > entity group relationships so that they can be used to retrieve their parent > without having to actually be serialized themselves. > > Brett chose to model fan-out with them but they can be used to model any > similar relationship. When used as Brett described there is never contention > because they are never updated. If you noticed Brett never discussed how the > actual lists are maintained :) which is a separate issue. > > The way I chose to maintain them is to store the list properties in a > separate and sharded group of entities associated with the person being > subscribed to. The sharding reduces but does not eliminate the potential for > contention on adding members to or removing members from the lists. > > You will need to decide if this fits your use case or if the simpler join > entity approach does. In either case there are trade offs but I wouldn't let > the number of records associated with join entities approach prevent its > use. If you were doing this with sql you would have a join table to model > the many to many relationship and it would have the same number of records. > > Jeff > > > > > > On Tue, Aug 24, 2010 at 5:44 PM, Eli Jones <[email protected]> wrote: > > Here is Brett Slatkin's IO talk from last year that starts off discussing > > ListProperty and why one might want to use it instead of a usual one-to-many > > model [though, it also points out that I don't know what I'm talking about > > :) since like Jeff mentioned, CPU is used up serializing, deserializing the > > List and it is not the same underneath as the usual one-to-many model.. so > > it seems my intuition is suspect. ]: > > >http://www.youtube.com/watch?v=AgaL6NGpkB8 > > > <http://www.youtube.com/watch?v=AgaL6NGpkB8>The audio is fried for the > > first few minutes but eventually kicks in.. (just watch captions until > > then). > > > On Tue, Aug 24, 2010 at 4:30 PM, skin <[email protected]> wrote: > > >> Thanks a lot Eli for sharing your thoughts on this. So what you are > >> suggesting is that I can do with just List<key> communitiesJoined in > >> User class. > > >> I need not have a mapping of users enrolled in community in Community > >> class. And whenever i need to retrieve the list of users in a > >> community, I should do select query with like Select * from Users > >> where communityId in List of communities. Ain't this going to impact > >> the response time to a greater extent? > > >> I think there has to be a trade-off between memory utilization and > >> response time depending on the requirement. Is there some research > >> done on which will be faster or some sample application which can show > >> us which technique will be better. > > >> -- > >> 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%2Bunsubscrib > >> [email protected]> > >> . > >> For more options, visit this group at > >>http://groups.google.com/group/google-appengine?hl=en. > > > -- > > 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%2Bunsubscrib > > [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.
