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.comgoogle-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.
