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 -~----------~----~----~----~------~----~------~--~---
