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: [EMAIL PROTECTED]
ICQ: 75955071 AIM: reebalazs
_______________________________________________
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 )
