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.
(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
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
...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...
Simplistix - Content Management, Zope & Python Consulting
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -