2009/2/1 Christian Theune <ct@gocept.com>:
On Sun, 1 Feb 2009 02:10:00 +0300 Dan Korostelev <nadako@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