[Zope-dev] [announce] for the CVS junkies: multiple ZODB mounting product.

[Shane Hathaway]

Anthony Baxter wrote:
> I'm curious - could you elaborate on the security issues of this? The
> convenience of not having to write an External Method each time you
> want to mount or unmount a ZODB is high. :)

Okay, I looked a little more and I see you're not allowing slashes in
the filename.  That's a decent solution.  Don't forget backslashes (for
MS Windows).  You may want to create mounted databases in a directory
other than /var, since there may be other sensitive files there.

If you're using more than one acl_users folder, remember that the
Manager role, regardless of user context, will give users the right to
use your product in their own directory.

One small change you should make: call the MountPoint._test() method
right after creating the new mount point.  It will ensure any mount
exceptions are propagated up correctly.

> > There are still some issues with mounted databases.  The primary issue
> > is that they interact strangely with ZClasses.  However, if you have
> > the same ZClass defined in both the primary database and the mounted
> > database, ZClasses seem to work fine.  (I wouldn't bet my company on
> > it, though.)
> 
> Yah, I've been thinking a bit about that, and it's not at all obvious
> how it should work. In my case, I want to be able to mount something like
> /partners/partnerA
>           partnerB
>           partnerC
> with each partner object a different ZODB. Unfortunately, the current
> implementation uses ZClasses in each one. So if I upgrade any one, I
> have to upgrade all of them. (and then we're back to the old 'how do
> you upgrade ZClasses' issue, which, unless I'm mistaken, has never
> really been resolved).

AFAIK you can just delete or rename a product and install the new
version of a set of ZClasses.

> > The other issues are that you can't easily undo nor manage mounted
> > databases.  That is more of a UI problem which could be solved by
> > product authors, however.  I envision a product that would create a
> > "mounted database manager" object.  Inside the database manager you
> > could add as many mount points as you want.  The database manager
> > object is where you would go to pack any of the mounted databases.
> 
> Yeah - the mount points are entirely invisible. One thing I'd considered
> doing was to make the Product provide a registry of mount points and their
> underlying FileStorages.

ZODB/Mount.py already provides such a registry, so you may want to use
that, although it applies to *all* mount points rather than some kind
of subset.

> A couple of issues I'd like clarification on:
> 
> Any mounted filestorage is searched for an object called 'Application'.
> I'm assuming it will also want things like Control_Panel &c as well. What's
> the bare minimum a new mounted FS needs? Right now, I'm copying Data.fs.in
> and blowing away the stuff in it, but nuking it's standard_html_blah is
> a bit more problematic. Would it be worth making a 'create new empty
> ZODB FS' function?

Actually FileStorage provides a nifty trick: you can just name a
database file and if it doesn't exist it will be created.  That could
be a security problem.  Or it might just be a good feature.  It will be
created with the "true" bare minimum, which doesn't even have an
Application object

The id of the MountPoint and the last item of the mounted path must
match for a subtle reason.  When ObjectManager looks up the object, it
uses the ID of the mount point.  The object it finds is assumed to have
the correct ID.  If there is no assurance of that, mounted databases
could cause some confusion for OFS.

One possibility you may consider is allowing the user to create a
FileStorage on the fly.  You can do one of two things: override
_getMountRoot(), which is a hook I provided for the very purpose of
accessing databases that have no Application object, or manually create
an Application object in the new database.  Either way, you must ensure
that the ID of the mounted object is the same as the ID of the mount
point.

> If you try to mount /Control_Panel/Products from a mounted ZODB, you get
> an 'Attribute Error: _owner'. I'm assuming the Control Panel is special
> cased by the ownership code when it's the main ZODB.
>
> How does this work with the Owner mods in recent CVS? If I remember
> correctly, objects keep a reference to their Owner - won't this break
> across ZODBs?

Hmm... I don't see why you would want to mount the Control_Panel,
except to fiddle with ZClasses.  I would suggest finding a way to get
ZClasses to operate more naturally might be a better approach.

Shane