[Zope-dev] Progress on zope intid/keyreference.

[Dan Korostelev]

2009/2/1 Christian Theune <ct at gocept.com>:
> On Sun, 1 Feb 2009 02:10:00 +0300
> Dan Korostelev <nadako at gmail.com> wrote:
>
>> I also just checked in a hack to make old keyreference objects
>> loadable if zope.app.keyreference is gone because a buildout doesn't
>> depend on it after upgrade:
>>
>> http://mail.zope.org/pipermail/checkins/2009-January/029890.html
>>
>> I wonder if that kind of quick hack is okay to be released for the
>> renamed package like zope.keyreference until we have a tool for
>> upgrading ZODB objects properly. May be there are any side-effects
>> that I don't know of?
>
> An alternative solution would be that people who have stuff in their
> databases that need it add zope.app.keyreference to their list of
> dependencies temporarily.
>
> It's a bit problematic in the sense that they might not have a direct
> dependency to zope.app.keyreference in their application but an
> indirect one which changed.
>
> We definitely didn't add that kind of code to our new packages and to
> me it doesn't look very appealing too although my alternative isn't
> great either.

My scenario was that someone uses zope.app.intid and/or
zope.app.catalog/z3c.indexer and he didn't declare a direct dependency
on zope.app.keyreference, because intid is pulling it already. Then,
we change zope.app.intid so it depends on zope.keyreference and not on
zope.app.keyreference. One runs buildout and BAH -
zope.app.keyreference is gone. Then he starts his zope instance and
gets borked objects and the whole catalog/intid thing not-working.
Here comes the big WTF:) Of course, we could state in CHANGES that he
should add zope.app.keyreference to his dependencies to make old
objects working, but that's kinda painful for all users to do that
IMHO (and there will be confusion and mailings about that for sure).
Also it keeps a deprecated package installed just because of one class
got moved. It would be great to have an simple way to repickle old
objects (possibly with changing their __class__ record a the storage
level). But until then, that solution looks nice to me, because it
will prevent people from spending much time trying to get the idea
about what happened and debugging it.

-- 
WBR, Dan Korostelev