[Grok-dev] Re: Grok and database generations

[Sebastian Ware]

Excellent!

I set my default attributes in the __init__ even when they aren't  
passed during instansiation. Adding them as class attributes sounds  
like a much better solution! This pattern would be great to use in  
sample apps.

I agree, this is solution covers my usecase just fine. Further down  
the line, maybe an import/export component would be useful. :)

Mvh Sebastian


4 sep 2007 kl. 18.40 skrev Philipp von Weitershausen:

> Sebastian Ware wrote:
>> I have been looking at the zope.app.generations package. For those  
>> who don't know about it, generations keeps track on your objects.  
>> The generations schema manager allows you to execute an evolve  
>> method in order to update objects to a required level of  
>> functionality. To determine which objects to update ituses a counter.
>> However, my most usual use case is that I have added some new  
>> default values to the __init__ method of a class and I want to  
>> update all the objects of that class to reflect this change. But I  
>> want to do this without having to write any extra code. I just  
>> want to sync my objects...
>> Is there any simple and smart way I could do this?
>
> Yup. It's called class attributes. When an instance doesn't have a  
> particular attribute, but a class does, the class attribute will be  
> used. When overwritten, it will be done so on the instance. For  
> example::
>
>   class Foo(object):
>
>       # make sure old instances also get this attribute
>       attr = default_value_for_old_instances
>
>       def __init__(self, attr=some_default):
>           self.attr = attr
>
> So if you have an instance of 'Foo' that was created before  
> __init__ set the 'attr' attribute, it will now be possible to say  
> 'foo_instance.attr' and it will resolve to  
> 'default_value_for_old_instances'.
>
>> If not, would this not be an excellent feature to add to Grok?
>
> For simple cases, I think defensive programming (e.g. gracefully  
> handling the absence of attributes) and tricks like I've shown  
> above work well enough that we don't need something special in Grok.
>
> *If* we have to introduce something to Grok, then it'll likely have  
> to handle trickier things as well. But tricky things are hard to do  
> in-place. They usually require good understanding of the way the  
> ZODB works. I think 'dump and reload' is much easier when you have  
> massive and/or tricky refactorings going on. As Tres says, it's not  
> a surprise that pretty much all RDBMS do it this way.
>
>
> -- 
> http://worldcookery.com -- Professional Zope documentation and  
> training