[Dbix-class] copying between databases

Matt S Trout dbix-class at trout.me.uk
Fri Feb 10 00:58:29 CET 2006


On Thu, Feb 09, 2006 at 05:37:05PM -0600, Brandon Black wrote:
> 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 bulk
> > 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.

Actually, that should be pretty easy to implement. Just wrap the appropriate
methods on Storage (insert, update, delete), serialise @_ less $self and
dump that into the table.

-- 
     Matt S Trout       Offering custom development, consultancy and support
  Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +



More information about the Dbix-class mailing list