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