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

[Anthony Baxter]

>>> Shane Hathaway wrote
> 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).

Bah. Silly backwards operating system. Ok dokey.  

> You may want to create mounted databases in a directory
> other than /var, since there may be other sensitive files there.

I thought about that, then thought 'that can wait for another day'. 
This is muchmuch simpler to implement.

> 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.

Hm - it's not possible for a Manager in a higher level to remove
privileges from a manager defined in a subfolder, I think. A pity.
Will document it.

> 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.

Ok dokey. I've just made a change to my code for both of these, 


> > 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.

So long as the classid stays the same. There's also a scaling issue - if
I have dozens of objects, this will be bad. I've got a solution for this
case - the stuff that goes into the sub-ZODB will be redone to only use
python-created objects.


> 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.

Yeah, I was going to try and hook a mounted databases tab into the Control
Panel. Zope gets an /etc/mtab :)

> 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

Yep, I discovered that. Since it breaks without an Application, 
and it might be a security problem, I just disabled it - the file 
must exist first. 


> 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.

I also hit this. Much confusion on the part of poor little Zope. The code
now will only let you specify an 'id' if you're mounting the root of a ZODB
(since the default ZODB doesn't have an id on it's root object.) This may 
not be the right thing to do, but I couldn't figure out an appropriate way
to do it otherwise.

Hm, maybe a small script in utilities that will create a real bare minimum
ZODB with an Application and a Control_Panel &c. might be the go here.

> 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.

I think I'm going to need to revisit the code tomorrow morning and write
the little 'ZODB maker'.
 
> 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.

Yep, you figured out what I was doing - it was more a matter of 'should
it work this way?'
-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.