[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