That's at least interesting from an update standpoint. If I read that correctly the biggest overhead is the DS Put operation, so the optimization of moving everything to single entry ID/Key/Value stores would cause problems during updates. Though as a difference I'm using the Entity object directly not the Django Model abstraction. Was there any noted performance differences with that test (eg. Are the *Property bits using a lot of time)
Josh Heitzman wrote: > See > http://groups.google.com/group/google-appengine/browse_thread/thread/a29a4b1dd606f52e > regarding the mcycle consumption impact of having lots of fields. > > On Oct 16, 9:11 pm, David koblas <[EMAIL PROTECTED]> wrote: > >> I'm storing application preferences in the datastore, they come in a >> variety of types. As I see it I've got three choices for implementation: >> >> * Name / Blob >> -- "general" has a json encoded object of all of the sub-settings >> * Name / ID / Lots of Fields >> -- Where ID = "general" or "user" (etc.) and different fields in >> each entity >> * Name / ID / Key / Value >> -- Where you query out all of the "user" settings and >> re-construct an object from it. >> >> My gut feel is that #2 is preferable, since it avoids double encoding >> the data and doing a query out of a large number of records in the later >> case. >> >> 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 [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 -~----------~----~----~----~------~----~------~--~---
