[Dbix-class] copying between databases
alan.humphrey at comcast.net
Fri Feb 10 01:14:04 CET 2006
Good idea. The only problem I see off the top of my head is allowing
"partial" copies to production. Some records may be in a halfway state and
not ready for prime time so we couldn't just play back the entire log.
Figuring out which records in the log are related doesn't sound like a
From: dbix-class-bounces at lists.rawmode.org
[mailto:dbix-class-bounces at lists.rawmode.org] On Behalf Of Brandon Black
Sent: Thursday, February 09, 2006 3:37 PM
To: dbix-class at lists.rawmode.org
Subject: Re: [Dbix-class] copying between databases
On 2/9/06, Alan Humphrey <alan.humphrey at comcast.net> wrote:
> OK, I'm stumped again. I tried your technique, modified to allow more
> freedom for updates (as opposed to inserts). That quickly led to the
> realization that many-to-many relationships meant we'd be spidering the
> of the database on each "publish". No good.
> So I decided to take the 80% solution and just update directly related
> records. The result is this:
Just another random idea, but possible a more robust (but probably
more difficult to implement) solution would be to add some optional
support to DBIC to do transaction logging at the DBIC level.
Essentially you'd specify a special table in the database as your
transaction log (it would have an auto-inc PK and a long text field
basically), and every time DBIx::Class issues an insert/update/delete
operation via the usual mechanisms, it first logs the statement to
that table. Then for migration to production you can just replay the
statements in that table in-order on the production db, and delete
them the staging log table as you commit them to production.
More information about the Dbix-class