Here's my proposal, assuming it can be done: 1. Create default database.
2. Run a test 3. If a test has fixtures, check for, and if not, copy base table to ``name_<hash_of_fixtures_list>``. 4. Start transaction 5. Run Tests 6. Roll back I think that pretty much would solve all cases, and assuming you reuse tons of fixtures it should be a huge benefit. Also if the begin/rollback aren't good enough, and we can already "copy" a database, then we could just continually copy databases each time (assuming its fast). On May 19, 6:12 am, Hanne Moa <[email protected]> wrote: > On 18 May 2011 01:46, Erik Rose <[email protected]> wrote: > > >> Is there a sensible to way "copy" databases in SQL? > > > SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a > > table. It's supported in MySQL at least. You could then do a bunch of > > INSERT INTO ... SELECTs if you deferred foreign key checks first. > > Sometimes, in order to rescue data from an overfull table (because the > cleanup-job had died and a DELETE would take too long) I've done the > following: > > - start transcation > - rename bad table > - receate the table (CREATE TABLE x LIKE would work) > - INSERT INTO ... SELECT good data into the recreated table from the > renamed table > - drop renamed table > - end transaction > > This works even when the system is up and running, on production servers. > > HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
