The initialization code seems very light, only 3 object creation and 4 object attributes assignment without touch both memcache and datastore. I think your code is correct, a local singleton map shouldn't be needed.
On Nov 1, 9:39 pm, josh l <[EMAIL PROTECTED]> wrote: > Bill, > > Thanks for the response. > I noticed of course you're using db.models and the associated > get_or_insert at the shard level. My question, though not well > worded, was really regarding whether the method I plan to use to > instantiate your counter object (specifically, checking the vars() > dict and going from there) seemed reasonable,or had any negative > implications on a system like GAE. > > As I see it, any code that uses your new counter object will need to > deal with instantiating it somewhere, and the example used in your > older version won't fit (since again it is using the get_or_insert on > a db.model Counter rather than a python object). Perhaps the answer > is so obvious it wasn't worth asking, but perhaps others might have a > similar question when wondering how best to actually implement it and > ensure the variable name they wish to use for the counter is not > taken, and that they're not unnecessarily instantiating multiple > Counter objects for no reason. > > Cheers, > > -Josh > > On Nov 1, 2:13 pm, Bill <[EMAIL PROTECTED]> wrote: > > > > With the new code, we have a python object rather than a model I can > > > get_or_insert > > > My modified counter uses a simple python object (rather than a model) > > at the level above the shards. Shard models are still used so when > > you change a counter, you'll invoke a get_or_insert style transaction > > at the shard level. If you look at the other counter > > implementations, you'll see that a high-level Counter model stores > > data like counter name and number of shards. Since I handle counter > > names and # of shards at the program level, hardwired to particular > > tasks, my version simply bypasses those Counter entities as not > > necessary. > > > Stat-like tasks like your use case are a good fit for the approach > > I've taken because counter accuracy (although very likely) is not > > guaranteed. For example, if you have a string of datastore timeouts > > and your memcache goes away, the counter will be inaccurate. In cases > > where it's essential for accurate counts or knowledge that it's > > failed, simply returning errors and handling it on the client side > > seems better. > > > But unless I'm misunderstanding your question, you should be able to > > just always instantiate the Counter object and use it. > > -Bill --~--~---------~--~----~------------~-------~--~----~ 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-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
