[Grok-dev] avoiding ZODB breakage
Martijn Faassen
faassen at startifact.com
Tue Jun 10 09:33:36 EDT 2008
Hi there,
Philipp von Weitershausen wrote:
[snip]
> This isn't so much about deprecation, it's about providing module
> aliases for persistent objects (rather than raising warnings about API
> usage). This is a non-trivial thing to do automatically. Off the top of
> my head I can only think of ZODB's broken hook. Whenever ZODB encounters
> a pickle that it can't deserialize to an instance of a class (IOW, it
> doesn't find the class), it'll use the broken hook. In a standard Zope 3
> environment, zope.app.broken fills that hook. Grok could fill it, too,
> and through some magic determine whether a grok.Model instance is
> involved and then perhaps *somehow* track where it moved... Yes, I'm
> waving my hands here :)
>
> So, doing it automatically isn't easy. Besides that, I don't see how
> much we need helping. If we do it manually, you have to keep track of
> where you moved your classes anyway. And then you just need to do one of
> the following:
>
> a) introduce a module alias (if you've moved a whole module)
> b) or provide BBB imports in the old module
>
> Both aren't hard, in fact b) is pretty straight-forward. I don't think
> it gets any easier. You just have to *know* that you have to do it.
> That's really the trickiest part, I think.
The trickiest part will be easier if we make it absolutely trivial. I
think we should make it so the user doesn't have to care whether they
moved the whole module or not. I also don't want to tell people how they
should mess around sys.modules themselves to make module aliases (as I
understand a) still requires).
What about something like this?
class Foo(grok.Model):
grok.moved('foo.bar.baz', class_name='Bar')
so, if you move any class, you can indicate with grok.moved that you
moved it.
If you're dealing with something that's a content component, it'll fix
up module aliases and so on for you. It'll also do deprecation warnings
for people trying to import from it.
If you're moving a non-content component (as far as we can recognize
this, of course), it'll just set up deprecation warnings in the other
place (possibly creating the module if it's not around anymore).
This doesn't take care of all content upgrade related problems at all,
but should at least make refactoring more easy.
Regards,
Martijn
More information about the Grok-dev
mailing list