[Proposal] Drop Mount.py from ZODB 3.5
http://www.zope.org/Collectors/Zope/1800 describes some of the code problems with Zope's current way of mounting databases. ZODB 3.4 (still) has a Mount.py module, unused and untested by ZODB. Jim and I were both surprised today to discover that Zope (2.8) still imports it, so we can't drop it for ZODB 3.4 (Zope 2.8, and the ZODB 3.4 it uses, are both in beta). We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's "standalone" ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ...
Thu, 02 Jun 2005 19:38:02 -0400 Tim Peters wrote:
We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's "standalone" ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ...
Although this is not strictly an answer to the original question, I would take to opportunity to react and in the end ask for your opinion. I am asking this because I yet do not see entirely clear in the question of mounting; however, as you will see below, I could achieve my goal in a way. First, according to how much I see of it you are right that Mount.py does not belong to ZODB, and I personally would not even consider using this code for a standalone ZODB app since there are cleaner solutions to be considered. But, as far as Zope is concerned, I have to admit of just having used this code in an app that is currently under development. And here is my use case: The application in question is a complete re-write of an already existing zope application. Migration of the old data to the new application is a key question. There are several backups of the old data at hand that are made by repozo and that can be converted into Data.fs format. The initial migration of the data starts with mounting one of this Data.fs files into the filesystem of the new product, and then migrating the content from it to the new portal. Furthermore, I made testcase base classes for unittest that support migration by using any of the Data.fs files. This way I can have a sequence of migration sources stored in a directory and use automated tests to either test the migration from all of these sources, or I can pick any of the sources, migrate them and run my acceptance tests on the migrated content that is getting formed in the new application. Needless to emphasize the enormeous advantage that I gain with this in the flow of the development, and concerning the success of the future "sharp" migration that will have to work like a charm on the live system. So far for the case. As for the implementation, since the name of the Data.fs and the mount point are coming from parameters, I could not use the new "dbtab" style mechanism since these parameters cannot be statically defined in the configuration files. So I decided to subclass the MountPoint class and created a product that mounts a given Data.fs readonly to the given mount point. Now I would like to pose a question to all of you. I am of course not worried if Mount.py is getting phased out completely, since I would be able to take over the code from it into my subclass. But according to my use case described above, am I on the right track with my implementation? Or (supposing that Mount.py disappears) what would be the "canonical" way of achieving what I want from within Zope? -- Bala'zs REE' jabber + email: ree@ree.hu ICQ: 75955071 AIM: reebalazs
On 4 Jun 2005, at 08:07, Balazs Ree wrote:
Now I would like to pose a question to all of you. I am of course not worried if Mount.py is getting phased out completely, since I would be able to take over the code from it into my subclass. But according to my use case described above, am I on the right track with my implementation? Or (supposing that Mount.py disappears) what would be the "canonical" way of achieving what I want from within Zope?
For a migration situation like yours I would highly suggest you use a simple script that acts as a ZEO client to two ZEO servers, one holding the old data and one serving a fresh storage that becomes the migration target. The old and new product directories must be stitched into the PYTHONPATH so both codebases can be located. This isn't all that hard. jens
For a migration situation like yours I would highly suggest you use a simple script that acts as a ZEO client to two ZEO servers
Inspired by this post, I wrote just such a migration script and have posted it on Zope Labs: http://www.zopelabs.com/cookbook/1118424287 Thanks for the tip Jens. chad
Tim Peters wrote:
http://www.zope.org/Collectors/Zope/1800
describes some of the code problems with Zope's current way of mounting databases. ZODB 3.4 (still) has a Mount.py module, unused and untested by ZODB. Jim and I were both surprised today to discover that Zope (2.8) still imports it, so we can't drop it for ZODB 3.4 (Zope 2.8, and the ZODB 3.4 it uses, are both in beta).
We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's "standalone" ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ...
ZODB/Mount.py is dangerous. In the past few years, Jim and I have discovered necessary constraints on mounted databases, and ZODB/Mount.py has not been updated to reflect that thinking. The main problem is that ZODB/Mount.py does not bind each mounted connection with a specific root database connection; instead, mounted connections are free to be used with any root database connection. The result is that _v_ attributes that cross mount boundaries turn insane. I solved the connection binding problem when I wrote the DBTab product, but the solution required an ugly monkey patch. Later, DBTab got folded into Zope, but not the way I expected. By the time I saw the integration, it was the wrong time to fix it. (I don't blame anyone for this mistake; DBTab was complex and I didn't explain well enough how it worked.) So now there's a mess to clean up. I suggest: 1. Products/TemporaryFolder is the only code in Zope that uses ZODB/Mount.py. Before the Zope 2.8.0 release, put a copy of ZODB/Mount.py in Products/TemporaryFolder and change the import statement to import that copy instead. 2. With the last Zope reference gone, remove ZODB/Mount.py from ZODB 3.3, 3.4, and 3.5. If standalone ZODB authors really depend on it, they can get their own copy and change their own import statements. 3. Update Products/ZODBMountPoint/Mount.py to use whatever method ZODB 3.5 wants to use for mounting databases, removing the ugly ConnectionPatches. 4. Change TemporaryFolder to use Products/ZODBMountPoint/Mount.py and finally remove Products/TemporaryFolder/Mount.py. Shane
Shane Hathaway wrote:
Tim Peters wrote:
http://www.zope.org/Collectors/Zope/1800
describes some of the code problems with Zope's current way of mounting databases. ZODB 3.4 (still) has a Mount.py module, unused and untested by ZODB. Jim and I were both surprised today to discover that Zope (2.8) still imports it, so we can't drop it for ZODB 3.4 (Zope 2.8, and the ZODB 3.4 it uses, are both in beta).
We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's "standalone" ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ...
ZODB/Mount.py is dangerous. In the past few years, Jim and I have discovered necessary constraints on mounted databases, and ZODB/Mount.py has not been updated to reflect that thinking. The main problem is that ZODB/Mount.py does not bind each mounted connection with a specific root database connection; instead, mounted connections are free to be used with any root database connection. The result is that _v_ attributes that cross mount boundaries turn insane.
I solved the connection binding problem when I wrote the DBTab product, but the solution required an ugly monkey patch. Later, DBTab got folded into Zope, but not the way I expected. By the time I saw the integration, it was the wrong time to fix it. (I don't blame anyone for this mistake; DBTab was complex and I didn't explain well enough how it worked.)
So now there's a mess to clean up. I suggest:
1. Products/TemporaryFolder is the only code in Zope that uses ZODB/Mount.py. Before the Zope 2.8.0 release, put a copy of ZODB/Mount.py in Products/TemporaryFolder and change the import statement to import that copy instead.
I assume we are too late to affect 2.8.
2. With the last Zope reference gone, remove ZODB/Mount.py from ZODB 3.3, 3.4, and 3.5. If standalone ZODB authors really depend on it, they can get their own copy and change their own import statements.
3. Update Products/ZODBMountPoint/Mount.py to use whatever method ZODB 3.5 wants to use for mounting databases, removing the ugly ConnectionPatches.
4. Change TemporaryFolder to use Products/ZODBMountPoint/Mount.py and finally remove Products/TemporaryFolder/Mount.py.
Yup, but I think this needs to be a project for Zope 2.9. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Tim Peters wrote:
http://www.zope.org/Collectors/Zope/1800
describes some of the code problems with Zope's current way of mounting databases. ZODB 3.4 (still) has a Mount.py module, unused and untested by ZODB. Jim and I were both surprised today to discover that Zope (2.8) still imports it, so we can't drop it for ZODB 3.4 (Zope 2.8, and the ZODB 3.4 it uses, are both in beta).
We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's "standalone" ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ...
Tim, you should have noted, for the benefit of Zope users, that the itent was to move this module into Zope, where it belongs. Given Shane's comments, it would be much better, for Zope 2.9, to reimplement Zope mounting using ZODB's new multi-database support. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[Jim Fulton]
Tim, you should have noted, for the benefit of Zope users, that the itent was to move this module into Zope, where it belongs.
If I knew I was sending the msg to zope-dev, I would have <wink>. That is, this message was _intended_ to go to zodb-dev, but I got fooled into accepting my mailer's auto-completion suggestion after typing the "zo" part. There's more about the Zope issues on the Collector issue: http://www.zope.org/Collectors/Zope/1800
Given Shane's comments, it would be much better, for Zope 2.9, to reimplement Zope mounting using ZODB's new multi-database support.
Yes, and the Collector issue mentioned that. If Shane doesn't beat me to it, I'll add his migration outline to that issue. (And thank you, Shane! It sounds like the right plan to me -- but what do I know about Zope mounting <0.5 wink>.)
participants (6)
-
Balazs Ree -
Chad Whitacre -
Jens Vagelpohl -
Jim Fulton -
Shane Hathaway -
Tim Peters