Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

making DBI writes no-ops More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

Two not-so-good solutions (Score:1)

by ChrisDolan (2855) on 2006.12.13 10:51 (#52263) Homepage Journal

I have used the following two heavy-handed solutions in the past. Neither of them are good solutions for big databases, but they can get the job done where disk space is not a concern.

1) Once per day, replicate the database to a dev copy. Run all tests on the dev database, destructively

2) Copy-on-write. I wrote a DBI facade which intercepted SQL prepares and, upon seeing an insert or update, copied the table to a new table and thereafter altered all SQL to replace the name of the old table with the new one. This was brittle because it required parsing SQL, so I only implemented for the small subset of SQL that the client was using.

Reply to This

Get More Comments

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.