[Grok-dev] Grok schema migrations (was Re: Getting the application in views and viewlets)

[Kevin Smith]

Hey Kevin,

Actually, I stopped using zope.generations after learning how to program 
defensively from Phillip, see below.



On Sep 4 2007, 9:40 am, Philipp von Weitershausen 
<phil... at weitershausen.de> wrote:
 > 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
 > _______________________________________________
 > Grok-dev mailing list
 > Grok-... at zope.orghttp://mail.zope.org/mailman/listinfo/grok-dev


Kevin Teague wrote:
>>>
>> Well, it's content upgrades in general, and yes, it would be possible 
>> to build a nicer solution that what's available right now with 
>> zope.generations. It's just it needs some time investment of a few 
>> people to design it and implement it. It'd make a good sprint topic too.
>
> I am trying to get zope.app.generations working in a Grok app ATM. Has 
> anyone done this? Anyone have any example code? (I'm finding the 
> zope.app.generations docs a bit tough to get started with). Any 
> comment on what kind of improvements could be made over the existing 
> generations package?
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>
>