Hi Joel, jlegris wrote:
Clearly, transferring the Data.fs from the test server to the production server is insufficient given the user data mismatch. Therefore, it would seem that my only option, given the circumstances would be to manually replicate the configuration in the production server. However, my better judgment leads me to think that this isn't sensible. Is there no alternative?
If you have "settings" and "user data" (not sure exactly what that means in terms of which objects are which) in the ZODB, and you need to update some and keep some, the way I would go about it is as follows: - - Identify in your production data.fs what user data needs preserving - Export these to disk as .zexp files. - Drop in the new data.fs - Test - Import the user data from the .zexp files on disk Clearly, in your case treating the data.fs as a single monolithic entity will not work for you - you need a way of splitting up the two types of data that need to be treated in two different ways. I do the above fairly frequently - I have a Plone site that seems to be nomadic, and has passed through a number of data.fs instances in it's life. The only "gotcha" I've encountered is where the products were out of sync between instances. (Note that this is pretty much what Tino has already said - I'm just expanding on it a bit to try and get some "traction".) Is there any reason why the above would not work for you? I have a nagging feeling I'm missing something here...which I think flows form your use of the term "settings" - would you care to expand on what objects you are thinking of? -- Regards, PhilK Email: phil@xfr.co.uk PGP Public key: http://www.xfr.co.uk Voicemail & Facsimile: 07092 070518 "You'll find that one part's sweet and one part's tart: say where the sweetness and the sourness start." - Tony Harrison