[Zope3-Users] need guidance

[Chris McDonough]

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

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.

- C