Duncan Booth wrote:
Urm, that would involve taking a complete copy of the db at open
time...
Not knowing the details of the implementation I don't know that it would.
Knowing the details as I do, I'm telling you it would...
Got that, but the problem is that the test database isn't exactly identical
to the live one (e.g. the ldap config points to the test ldap server) but
Then fix the flakey test environment rather than applying even more
fragile machinery in an attempt to ignore the real problem ;-)
I'm sure we could script the tweaks needed. More significantly is the pain
involved in copying 10Gb from the live system onto dev on more than an
occasional basis.
It's still worth it...
The problem I'm trying to address is that sometimes we make mistakes when
updating the live server because of minor differences between the test and
live environments.
Ah, a flakey upgrade process too ;-) Take a look at Stepper. One of it's
main uses is to write upgrade scripts than can be consistently run when
doing upgrades and test upgrades on a development environment.
took some time and caused site errors until it was complete. I have a
script which I believe should do the migration quickly but I want to be
absolutely positive it is going to work without any hitches.
In your position, I would have little to no confidence that using
DemoStorage in the way you suggest would meet your requirements...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
