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