Duncan Booth wrote:
Can someone explain to me what is and is not safe to do with demostorage?
Well, that's a bit of a broad question ;-)
Say I have a zope setup involving a zeo server and clients, and I create another zope instance with <demostorage> wrapped around both <zeoclient>
Why would you do that?!
A bit of experimenting seems to indicate if I edit an object in the main system, the demostorage version picks up the changes until such time as I edit the same object in the demostorage instance.
Yep.
(So in other words, the connection from the demostorage front-end to the zeo-client isn't frozen at the point when the storage is opened which might have been a plausible alternative).
Urm, that would involve taking a complete copy of the db at open time...
What I'm a little worried about is the catalog. I'd guess that there is no guarantee that the demostorage instance gets a catalog which is consistent with the rest of the data (so I could easily get site errors in the demostorage instance), but there should be no danger that any changes I make can affect the live site and restarting the demo instance would get it back into a consistent state, at least for a while. Is that a reasonable interpretation?
...ish. But really, what you're doing is not what DemoStorage was designed for and will likely end in tears or a lot of hair pulling...
What I'm hoping to achieve is a way of testing upgrades on our live system in an environment as close as possible to the real live environment, but without actually affecting the live system in any way. Demostorage seems to offer that as an option.
It really doesn't ;-) Do this kinda testing the same way that everyone does: build yourself a uat environment that mirrors your production environment, maybe with a few less zeo clients, run it off a copy of your production zodb and then test there... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk