Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Users

Re: - database transfer

 

 

Zope users RSS feed   Index | Next | Previous | View Threaded


jim at Digicool

Dec 8, 1998, 10:56 AM

Post #1 of 7 (522 views)
Permalink
Re: - database transfer

Paul Everitt wrote:
>
> As mentioned there is an undocumented facility called manage_exportHack
> and manage_importHack:

(snip)

Note that these are undocumented and have the names they do because they
are not a permanent part of the api. They provide an interim solution.
I don't have a problem with putting a GUI in front of these for now.

Jim

--
Jim Fulton mailto:jim [at] digicool
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.


jim at Digicool

Dec 8, 1998, 10:54 AM

Post #2 of 7 (504 views)
Permalink
Re: - database transfer [In reply to]

David Ascher wrote:
>
> Is it easy to take the DB from a Zope server and plop it into another Zope
> server? I'm not talking about load-sharing, but staging of servers -- I
> tend to do my web management on a local machine, and have a periodic job
> upload the files into the less-easily configured 'public' server. Can I
> just tar the var/ directory and misc. external methods and move that over,

The short answer is yes. You'll need to be careful to shutdown the app
before moving the files over. It might be nice to have a tool that
makes this easier, or even allows it to be done without shutting down.
If you want to pursue this, I'd be happy to help you get started.

> or are there other dependencies?

Well, of course, both sites need to have the same products and other
Python modules installed.

Jim

--
Jim Fulton mailto:jim [at] digicool
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.


jim at Digicool

Dec 8, 1998, 11:05 AM

Post #3 of 7 (506 views)
Permalink
Re: - database transfer [In reply to]

"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 [at] digicool
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.


jim at Digicool

Dec 8, 1998, 11:09 AM

Post #4 of 7 (505 views)
Permalink
Re: - database transfer [In reply to]

"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 [at] digicool
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.


petrilli at amber

Dec 8, 1998, 11:19 AM

Post #5 of 7 (504 views)
Permalink
Re: - database transfer [In reply to]

On Tue, Dec 08, 1998 at 06:05:35PM +0000, Jim Fulton wrote:
> "Christopher G. Petrilli" wrote:
> >
> > [. I propose a mind-bending connection between Zope servers to move dbs]
>
> 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.

Well, I would see this as a total replacement effectively of a "tree"
inside the database. Maybe I've got the wrong "image" in my head of how
things are stored in the database... entirely possible. Dynamic data
that would change should be in a different part of the database (a
differetn database?)

> > - Security is a BIG concern
>
> Yes, this has to be done carefully.

Ayup, it's what I do for a living---didn't you always wonder why I was
so twisted? :-)

> > - 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.

Versioning is sessions, see below, I just sorta pre-adopted it before it
was changed in names :-)

> 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.

A VC system could be useful though, but that's another painful idea for
another boring evening :-)

> > 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.

Actually, now that I try and explain what it is I'd want, it doesn't
work right in the object model anyway :-) I'm sure it's useful though,
truly I am! :-)

Chris
--
| Christopher Petrilli
| petrilli [at] amber


petrilli at amber

Dec 8, 1998, 11:22 AM

Post #6 of 7 (503 views)
Permalink
Re: - database transfer [In reply to]

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 [at] amber


jim at Digicool

Dec 8, 1998, 12:20 PM

Post #7 of 7 (507 views)
Permalink
Re: - database transfer [In reply to]

"Christopher G. Petrilli" wrote:
>
> On Tue, Dec 08, 1998 at 06:05:35PM +0000, Jim Fulton wrote:
> > "Christopher G. Petrilli" wrote:
> > >
> > > [. I propose a mind-bending connection between Zope servers to move dbs]
> >
> > 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.
>
> Well, I would see this as a total replacement effectively of a "tree"
> inside the database. Maybe I've got the wrong "image" in my head of how
> things are stored in the database... entirely possible.

The data is not organized as a tree, but as a mapping from object ids
to object data. Each (persistent) object gets it's own record in the
database.

> Dynamic data
> that would change should be in a different part of the database

You can certainly arrange things that way.

> (a differetn database?)

Wouldn't have to be a different database.

(snip)

Jim

--
Jim Fulton mailto:jim [at] digicool
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.

Zope users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.