So this style of Zope 3 development involves not using
ZODB so much for permanent storage, but instead as a
temporary scaffolding on which to hang the current version
of class instances and their content. When you refactor
your classes and interfaces, you just re-instantiate everything
into the ZODB to recreate the site.
For development, yes.
It sounds great, except not all data can be simply regenerated.
For stuff like port numbers and configuration, fine, it can be
in ZCML or embedded in Python scripts. But the site content
generated by end users has to be stored somewhere, too,.
If you throw away your ZODB and regenerate it, what happens
to that data? Does your regeneration script transfer
all that data to the newly generated ZODB?
While you're developing, it's much easier because the *content* in
your ZODB doesn't typically have any value during development. If it
does have value during development, you have a development model
that's not similar to mine.
But obviously, after you go into production, the content does have
value, and preserving this value is the purpose of GenericSetup for
Zope 2. It's a "dump and reload" solution which allows you to create
a represention of your ZODB data and its associated hierarchy as
files on a filesystem. You can basically push a button to dump the
data in your ZODB ro files, and then create a new ZODB, instantiate
the tool, and push a button to reload it. Zope 3's "filesystem
synchronization" capability is similar in concept, although I don't
know if that has been maintained recently.
I'd be interested in seeing the particulars of how
you guys do that stuff.
I do it all the time for customer jobs and there are examples in CMF
for Zope 2 (e.g. the "SiteGenerator") but I don't have any code that
uses Zope 3 that does site generation.
I've yet to run across a direct
mention of how to create an arbitrary ZODB and
start reading and writing objects. That seems to
be a big piece missing from my understanding
of how to work with Zope 3. Every ZODB example
I've seen in the books seems to involve creating a content
object that can be added via the ZMI. However, I'm
not finished with either book, and I have very likely
There are tons of examples about how to access ZODB data outside of
the context of Zope around, do a little googling. The thing that
might make it a little mindbending is that "accessing data in ZODB"
is just.. Python. You open the database, get the root Zope object,
and then traverse to an object in the database (usually via getattr
or getitem or whatever the folder API is) and call methods on it or
read attributes from it or whatever. There's really not much to it.
It's largely the same as writing code in your content classes, but
you can do it from a Python prompt. Zope 2 has "zopectl debug" which
dumps you off at a Python prompt with the name "app" built in to the
root Zope object.
Note that this is not particular to any version of Zope. Zope is
just a consumer of ZODB, and the issues are the same no matter what
consumer of ZODB you're using.
Zope3-users mailing list