Seperate Development ...
Hi ! Using a Windows Server (which I had to do), I have a production zope site that needs to be always online. Unfortunately I am quite a newbie using zope, so I have a question: I would like to setup a second site for development, perhaps with an automatic way to move this site to the production site. Can I just copy the Data.fs ? Do I need to stop the service before and restart it afterwards or could this even be done "on the fly" ? Bernd
you must stop for a straight Data.fs copy operation and then restart. otherwise you risk corrupting your ZODB. make sure your development sandbox has all the same products and the same versions of everything installed. jens On Tuesday, May 21, 2002, at 03:52 , Bernd Schoeller wrote:
Hi !
Using a Windows Server (which I had to do), I have a production zope site that needs to be always online. Unfortunately I am quite a newbie using zope, so I have a question:
I would like to setup a second site for development, perhaps with an automatic way to move this site to the production site. Can I just copy the Data.fs ? Do I need to stop the service before and restart it afterwards or could this even be done "on the fly" ?
Bernd
incomplete records that did not get flushed to the file system on the source side and on the target size you would be pulling an existing Data.fs out from under a running server and replace it with something new. i have seen whole Data.fs getting truncated to zero content that way. jens On Tuesday, May 21, 2002, at 07:45 , Chris Withers wrote:
Jens Vagelpohl wrote:
you must stop for a straight Data.fs copy operation and then restart. otherwise you risk corrupting your ZODB.
How so?
cheers,
Chris
On Tue, May 21, 2002 at 09:08:47AM -0400, Jens Vagelpohl wrote: | incomplete records that did not get flushed to the file system on the | source side and on the target size you would be pulling an existing Data.fs | out from under a running server and replace it with something new. i have | seen whole Data.fs getting truncated to zero content that way. Have you seen this on windows? Does zope open and close the Data.fs frequently? The reason I ask is because windows has a crappy way of keeping track of open files. It uses the name, and thus disallows any modification of an open file. That's one reason it is so reboot-happy and why you shouldn't have programs running when you run an installer. (for an example scenario, try running 'bash.exe' and upgrading libcygwin1.dll) The effect is that, if zope keeps Data.fs open, then you have to stop zope anyways to do anything to the file. -D -- For society, it's probably a good thing that engineers value function over appearance. For example, you wouldn't want engineers to build nuclear power plants that only _look_ like they would keep all the radiation inside. (Scott Adams - The Dilbert principle) GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
i don't know anything about windows, i just don't use it. i know that during normal operation zope does not open and close the file willy-nilly. it gets opened on startup and closed on shutdown. if the shutdown happens in an orderly fashion all unwritten records get flushed to the file system correctly. jens On Tuesday, May 21, 2002, at 09:40 , dman wrote:
On Tue, May 21, 2002 at 09:08:47AM -0400, Jens Vagelpohl wrote: | incomplete records that did not get flushed to the file system on the | source side and on the target size you would be pulling an existing Data.fs | out from under a running server and replace it with something new. i have | seen whole Data.fs getting truncated to zero content that way.
Have you seen this on windows? Does zope open and close the Data.fs frequently? The reason I ask is because windows has a crappy way of keeping track of open files. It uses the name, and thus disallows any modification of an open file. That's one reason it is so reboot-happy and why you shouldn't have programs running when you run an installer. (for an example scenario, try running 'bash.exe' and upgrading libcygwin1.dll) The effect is that, if zope keeps Data.fs open, then you have to stop zope anyways to do anything to the file.
-D
Jens Vagelpohl wrote:
incomplete records that did not get flushed to the file system on the source side and on the target size you would be pulling an existing Data.fs out from under a running server and replace it with something new. i have seen whole Data.fs getting truncated to zero content that way.
I didn't quite follow that, can you explain a bit more? How would the thing you're copying become of zero length? cheers, Chris
i don't know. i have seen it happen. that's all. jens On Thursday, May 23, 2002, at 10:09 , Chris Withers wrote:
Jens Vagelpohl wrote:
incomplete records that did not get flushed to the file system on the source side and on the target size you would be pulling an existing Data. fs out from under a running server and replace it with something new. i have seen whole Data.fs getting truncated to zero content that way.
I didn't quite follow that, can you explain a bit more?
How would the thing you're copying become of zero length?
cheers,
Chris
Jens Vagelpohl wrote:
i don't know. i have seen it happen. that's all.
Don't cop out like that ;-) If you've seen it happen, then you must at least know the circumstances, and I'd be surprised if you hadn't dug out an explanation... cheers, Chris
i do know the circumstances: copying a Data.fs into a ZEO server that was not shut down while this copy operation took place. i'll have to surprise you on the explanation. i did not dig it out. i did not have time for that, and i don't have time for it now. the effort to do the right thing and simply stop ZEO for this copy operation was much smaller than trying to figure out where the "problem" is. i don't even consider it a "problem". even you should realize that there is no database that allows you to just replace its filesystem data "on the fly" without the application's knowledge. IMHO there is no problem in saying "just don't do it, stop ZEO before copying a new Data.fs into it" and that's the end of it. jens On Thursday, May 23, 2002, at 01:18 , Chris Withers wrote:
Jens Vagelpohl wrote:
i don't know. i have seen it happen. that's all.
Don't cop out like that ;-)
If you've seen it happen, then you must at least know the circumstances, and I'd be surprised if you hadn't dug out an explanation...
cheers,
Chris
Jens Vagelpohl wrote:
i do know the circumstances: copying a Data.fs into a ZEO server that was not shut down while this copy operation took place.
Ah, okay, that's much less surprising. I thought you meant copying _from_ a server that was running was likely to cause problems on that server. That should be fine, right? I can think of _loads_ of reasons why copying _into_ a running ZEO server would break it spectacularly ;-) cheers, Chris
I would like to setup a second site for development, perhaps with an automatic way to move this site to the production site. Can I just copy the Data.fs ? Do I need to stop the service before and restart it afterwards or could this even be done "on the fly" ?
Try to keep the production site as clean as possible and when you transfer stuff over from the development site, try to use the Export/Import function or package up your classes and move them across only. On the development site you'll probably install lots of new products and create dummy objects all over the place. My suggestion is that you try to modularize (the spelling on that word?) your important stuff as much as possible. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.361 / Virus Database: 199 - Release Date: 2002-05-07
participants (5)
-
Bernd Schoeller -
Chris Withers -
dman -
Jens Vagelpohl -
Peter Bengtsson