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.