Re: [Zope] - database transfer
"Christopher G. Petrilli" wrote:
On Mon, Dec 07, 1998 at 11:46:31AM -0800, David Ascher wrote:
On Mon, 7 Dec 1998, Christopher G. Petrilli wrote:
I'm going to prove I really have no life to Paul, but... I was just thinking of this same problem last night in the shower...
Let's work with this:
zope_a - Internal development/testbed zope_b - Production/consumer side [...]
Etc. Yes, this is exactly what I want. As long as it's free your check is in the mail as soon as it's ready. =)
I wait with baited breath... and here you didn't know I was into Bass fishing :-)
Seriously, I wanna think a bit more about this, because it fits into some ideas that Jim/Paul/Amos have promulgated vis a vis Zope2, and how it will be able to be distributed... so we really need to think about how 2 Zope systems will communicate in general (Fnorb?) rather than this one speicific instance.
I think that this is a different beast. We have plans for essentially "client-server" support for the Z Object Datrabase, initially by hosting the object database in an RDBMS. This would not really solve the problem that started this thread. David wanted to be able to do development on a machine that has a very slow (or, reading between the lines, intermittent) connection to the production server. In a client-server model, the development server would be hampered by a slow connection to the database server. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
On Tue, Dec 08, 1998 at 06:09:46PM +0000, Jim Fulton wrote:
I think that this is a different beast. We have plans for essentially "client-server" support for the Z Object Datrabase, initially by hosting the object database in an RDBMS. This would not really solve the problem that started this thread. David wanted to be able to do development on a machine that has a very slow (or, reading between the lines, intermittent) connection to the production server. In a client-server model, the development server would be hampered by a slow connection to the database server.
Also, as performance becomes more and more important, it's going to be necessary also to perhaps use seperate databases for production/development, not to mention for reliability. I know this isn't a problem yet, but certainly it could be very soon with a successful implementation. I know we always ran seperate versions of Oracle for test/development (for other reasons too) on seperate machines, even though "slow conections" werent' the issue. Even if you could show that it shouldn't be a concern, it is how people do things, and they aren't want to change :-) Chris -- | Christopher Petrilli | petrilli@amber.org
participants (2)
-
Christopher G. Petrilli -
Jim Fulton