On Mon, Jul 20, 2009 at 06:44:09AM -0400, Jim Fulton wrote:
On Mon, Jul 20, 2009 at 2:48 AM, Michael Howitz<mh@gocept.com> wrote:
Do you search this one?
zope.app.zopeappgenerations.ZopeAppSchemaManager
Ah, thanks.
So this is all rather confusing. Marius' branch refer to files that aren't in zope.app.component anymore.
This probably means that if one wants to use an old Zope 3.2 DB with Zope 3.5 (is that a good name for the current "trunk" KGS?), one needs to upgrade to 3.4 and then run a custom generation script to activate and dirty all objects to cause re-pickling. Right?
The relevant code has moved to zope.site, so, unless I'm missing something, Marius' patches seem largely irrelevant.
For some definition of relevance. They're irrelevant for KGS 3.5, since old DB won't work in any case. They're relevant for KGS 3.4, which appears to be a necessary intermediate step in any migration from 3.2 to 3.5.
The evolve4 script in zope.app.zopeappgenerations refers to a _evolve_to_generation_4 method that isn't anywhere on the trunk anymore, but is in the back35.py file that Marius edited. It looks like the schema manager in zope.app.zopeappgenerations needs to get cleaned up.
My suspicion is that it would be best to add a schema manager in zope.site that makes sure that the root site manager has a proper __bases__.
I also wonder if __bases__ on subsites are migrated correctly. We don't use subsites so the question is largely theoretical. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development