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

(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?




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
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to