[Grok-dev] Grok schema migrations (was Re: Getting the application
in views and viewlets)
kevin at mcweekly.com
Fri Jun 20 20:37:43 EDT 2008
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
> > 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
More information about the Grok-dev