At 06:00 PM 4/28/01 +0200, Christian Scholz wrote:
Hi!
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 anyway 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 production 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.