This is probably not a good idea. What are your access pattens for this entity? How many accounts do you usually need to retrieve at once? How often is an account updated?
If you normally access just a few accounts, then you are incurring the cost of retrieving all of them every time unnecessarily. When you need to update an account you are incurring the cost of deserialization/serialization for the entire list. This will also lead to contention when multiple users are updating their accounts. -Chris On Wed, Jul 14, 2010 at 11:46 PM, coltsith <conla...@gmail.com> wrote: > I had an idea the other day, but know there's probably some issue I'm > not realizing. > > Let's say you have an Account object that represents a registered > user. Instead of having multiple Account objects that you persist to > the datastore, why not have 1 object (ie AccountList) that you > persist, and that object has an array all the Accounts. > > So if you want to pull up multiple Accounts or even all of them, it's > just 1 query to the datastore to get AccountList. > > What major issues (if any) would I run into using this model? > > Thanks > > -- > 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-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> > . > 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 google-appeng...@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.
