At 06:00 PM 4/28/01 +0200, Christian Scholz wrote:
>First of all one note to the sql attribute provider: My problem seems to
be solved
>now. Actually it was quite easy.. dunno why it took the long way.. thanks
>to Phillip and Steve!
>But I have another problem now: I have some rack with persistent objects
in it.
>Now I want to migrate my site to production. Problem: If I do this more often
>and the objects are within some Rack, then also these get copied to the
>site and the old objects will get deleted there.
>Is there any way to first backup the contents of some rack? Or do I need to
>construct it all as external storage? (basically most things are in an sql
>db already, I just put image data etc. into the rack directly as I don't need
>relational access to it..)
>Actually I know how to read the objects from the BTree but I dunno how to
>store them again into another rack (which has the same storage attribs of
>course). Can I simply use _setRack()? I guess not, eh? :)

My suggestion would be to copy the Rack using normal Zope copy/paste
(assuming that works), and then from Python "poke" the old rack's BTree
into the new Rack.  Then delete the old rack.  This really sucks as a
mechanism, however.

The way I originally intended to solve this issue was to allow the Rack's
persistent data to be stored outside itself somewhere.  That's why some
versions of ZPatterns have a little dropdown on the Storage tab which only
has one selection - stored inside the rack.  The idea was that maybe
someone would create "storage providers" which could be kept external to
the Rack and then acquired.  This could still be done, if somebody wanted
to take up the coding.  Then you could upgrade/replace a rack without
damaging data stored in it.  Ty and I never got around to doing it because
so far, all our ZPatterns apps have not had any ZODB-based data, only SQL
and LDAP.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to