Saturday, January 31, 2009

How to protect your Data.fs

I'm currently enjoying some very productive time at this years Baarn's UI sprint organized by Informaat in the Netherlands. While I'm primarily working on the testing group, where we try to get a full-roundtrip Selenium-based testing story in place, we were looking into ZODB demo storages for different reasons.

As a side effect we came up with the following little snippet:
from ZODB.DemoStorage import DemoStorage
from Zope2.App.startup import getConfiguration

# Read the database configuration from zope.conf
dbtab = getConfiguration().dbtab

# Get the root storage and open it
base_storage = dbtab.getDatabase('/', is_root=1)._storage

# Wrap an in-memory demo storage around our normal storage
Storage = DemoStorage(base=base_storage)
If you put this code into a file called in your INSTANCE_HOME, your Zope will start up with its normal file storage, but wrapped in a demo storage.

With this file in place all changes you do will only be written and kept in memory. Once you restart the server, you are back to the state of the Data.fs on your file system.

The next time you want to experiment with a large customer Data.fs, show a demo based on some predefined content, provide a Live-CD or host a demo site, this might come in handy. If you want to feel even more on the save side, opening the underlying storage in read-only mode or ensuring that the operating system level user doesn't have write permissions to the file could be additional measures to take.


  1. More simpler:

    you can wrap your storage configuration with your zope.config inside a 'demostorage' tag.

  2. Andreas took the words out of my mouth; I loaded your blog from my RSS reader just to add a comment to the same effect :-)

    .. storage to be wrapped

    and you're done. :-)

    Of course, plone.recipe.zope2instance doesn't support this yet, as it doesn't yet support beforestorage either.

  3. Not necessary relevant to your tip, but have you seen collective.ploneseltest?


  4. Modifying your zope.conf directly is also one possibility. In our case we take existing buildouts and want to turn them into a read-only-mode in order to run functional tests against the live application. It's easier to add a file than to parse and modify the database configuration from the zope.conf file.

    @martin: My new package is based on ideas from ploneseltest and others. Though we'll probably not finish it and use a bit of a different approach.