[Grok-dev] avoiding ZODB breakage

[Martijn Faassen]

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