[Zope] - database transfer

[Jim Fulton]

"Christopher G. Petrilli" wrote:
> 
> On Mon, Dec 07, 1998 at 09:43:26AM -0800, David Ascher wrote:
> >
> > [ The idea of exporting databases, etc ]
> >
> > Right -- the other reason is that I do my editing on a server to which I
> > have very good connectivity, but which isn't available to the world.
> > It's my own staging area.  The manage_export hack (or a non-hack
> > replacement) should do the job in the future.  Thanks
> >
> 
> 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
> 
> What I'm imagining is that on zope_a you create an object
> (RemotePublisherDestination) that represents zope_b, and on zope_b you
> create a object (RemotaePublisherSource) that represents zope_a.  Each
> of these would have a shared secret associated with them for
> authentication (this could be extended to more trusted forms later).
> 
> Now, Jane works on her website ideas on zope_a, trying ideas, blowing it
> up, using Versioning to try things, commit and revoke them, and when
> she's done with the whole package, she tags the tree to publish, clicks
> a button, and automagically, the whole thing is encapsulated in a
> package (marshalled, etc) that is then shipped over to
> RemoatePublisherDestination via a secure channel.
> 
> Once the package is there, the zope_b site would examine it, and then
> commit it into the POS as a version.  This allows to examination to make
> sure that all the Acquisition tricks are working correctly, and not
> broken, and can be commited as a whole thing.
> 
> Why is this useful?  Overtime, I'd like to be able to run a Zope server
> at my house that I work on things with, and then move that up to the T1
> attached one when I'm done.  It's just too slow otherwise.  Also, it
> would be helpful in the case of ISPs, etc., who could let their
> customers break things on their own sites before working interactively
> with teh real thing---performance and all.

I agree that this could be useful and is probably doable, but I suspect 
that the details could mount pretty quickly.  It would be alot easier if 
the objects modified on the development site were *never* modified on the
production site.


> What's wrong?
>         - Acquisition problems could get weird

Maybe, but not so bad if the two sites are sufficiently
in sync.

>         - Security is a BIG concern

Yes, this has to be done carefully.

>         - Does this defeat the point of versioning (*)

I don't think so.

>         - Lots of other things I'm sure others will point out
> 
> * - I see versioning as a way to play with ideas in a framework that can
> be undone trivially, show them to others,etc, without breaking the
> starting point. 

What do you mean by "versioning"? Do you mean undo? Undo is primarily
there to make it easy to recover from mistakes.

Sessions (soon to be renamed "versions", aka long-running-transactions)
provide an even better way to do this.

> It's not quite a VC system, which is a totally
> different question, no? 

Right.  It's *not* a VC system, although there are some 
similarities.

> One of the neat things that Illustra had (a
> OO-Relational database) is the concept of time-travel.  You could see
> the database through a time-point. 

BoboPOS/SimpleDB was designed to support this sort of thing, although
we've never really used it.  There are API's there, although there
since they haven't been used, I don't know if they still work.

I could imagine having Zope 2 feature that allowed you to have a read-only
view of some past version of a web site.

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.