Re: [Zope-dev] Progress on zope intid/keyreference.
On Sun, 1 Feb 2009 02:10:00 +0300 Dan Korostelev nad...@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. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Progress on zope intid/keyreference.
2009/2/1 Christian Theune c...@gocept.com: On Sun, 1 Feb 2009 02:10:00 +0300 Dan Korostelev nad...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Progress on zope intid/keyreference.
I just finished working on zope's intid and keyreference packages. The whole key-reference stuff is now moved in zope.keyreference package and the new version of zope.app.keyreference is released that only contains compatibility imports, so it makes no sense to depend on zope.app.keyreference anymore - use zope.keyreference. All functionality of zope.app.intid, except ZMI stuff is moved to the zope.intid package. Old zope.app.intid package now only contains browser pages and add menu item as well as backward-compatiblity imports. So if you are not using ZMI - zope.intid is for you. Next, I'm going to split zope.app.catalog and check other packages for uses of zope.app.intid/zope.app.keyreference (I guess some sqlalchemy-related packages can depend on keyreference stuff). -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Progress on zope intid/keyreference.
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? 2009/2/1 Dan Korostelev nad...@gmail.com: I just finished working on zope's intid and keyreference packages. The whole key-reference stuff is now moved in zope.keyreference package and the new version of zope.app.keyreference is released that only contains compatibility imports, so it makes no sense to depend on zope.app.keyreference anymore - use zope.keyreference. All functionality of zope.app.intid, except ZMI stuff is moved to the zope.intid package. Old zope.app.intid package now only contains browser pages and add menu item as well as backward-compatiblity imports. So if you are not using ZMI - zope.intid is for you. Next, I'm going to split zope.app.catalog and check other packages for uses of zope.app.intid/zope.app.keyreference (I guess some sqlalchemy-related packages can depend on keyreference stuff). -- WBR, Dan Korostelev -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
