tags:

views:

549

answers:

3
+1  A: 

If you don't want to use command line tools, in other words you want to do it completely within say php or whatever language you are using then why don't you iterate over the tables using SQL itself. for example to check the table structure one simple technique would be to capture a snapsot of the table structure with SHOW CREATE TABLE table_name, store the result and then later make the call again and compare the results.

Have you looked at the source code for mysqldump? I am sure most of what you want would be contained within that.

DC

DeveloperChris
Well, mysqldump is 5K+ lines of GPL-ed C code with a lot of special cases...http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.1/annotate/head:/client/mysqldump.cIf I'm down to adapting it for my needs... I'd rather call it from command line then. (I'd still like to avoid this)
Alexander Gladysh
If you are open to command line utilities check out the excellent maatkit http://www.maatkit.org/tools.html
DeveloperChris
Thanks, but, if I'm down to using command line, I'll use mysqldump to reduce external dependencies. I'd still like to find SQL-query-only solution.
Alexander Gladysh
it would appear then you are back to writing your own queries. but maatkit has some very good functions designed to do similar to what you want, browsing the source should help its written in PERL so it should be relatively easy for anyone accustomed to c to read. in particular look at the mk-table-checksum for comparing tables.
DeveloperChris
A: 

Unless you build the export yourself, I don't think there is a simple solution to export and verify the data. If you do it table per table, LOAD DATA INFILE and SELECT ... INTO OUTFILE may be helpful.

I find it easier to rebuild the database for every test. At least, I can know the exact state of the data. Of course, it takes more time to run those tests, but it's a good incentive to abstract away the operations and write less tests that depend on the database.

An other alternative I use on some projects where the design does not allow such a good division, using InnoDB or some other transactional database engine works well. As long as you keep track of your transactions, or disable them during the test, you can simply start a transaction in setUp() and rollback in tearDown().

Louis-Philippe Huberdeau
Thanks, I do not want to use INFILE and OUTFILE, since I do not want to (explicitly) touch the filesystem from my framework code.
Alexander Gladysh
As for rebuilding the database — yes, I'm doing the same. The problem is that I have to test a custom "rollback" logic (not related to SQL transactions), where I'm "committing" several changes to DB and then "rolling back" them one-by-one, all in a single test.
Alexander Gladysh
+2  A: 

Given you're requirements, I think you are left with (pseudo-code + SQL)

tables = mysql_fetch "SHOW TABLES"
foreach table in tables
    create = mysql_fetch "SHOW CREATE TABLE table"
    print create
    rows = mysql_fetch "SELECT * FROM table"
    foreach row in rows
        // or could use VALUES (v1, v2, ...), (v1, v2, ...), .... syntax (maybe preferable for smaller tables)
        insert = "INSERT (fiedl1, field2, field2, etc) VALUES (value1, value2, value3, etc)"
        print insert

Basically, fetch the list of all tables, then walk each table and generate INSERT statements for each row by hand (most apis have a simple way to fetch the list of column names, otherwise you can fall back to calling DESC TABLE).

SHOW CREATE TABLE is done for you, but I'm fairly certain there's nothing analogous to do SHOW INSERT ROWS.

And of course, instead of printing the dump you could do whatever with it.

Rob Van Dam
How much information would I miss with this approach?
Alexander Gladysh
You wouldn't miss any data from your tables because the `SHOW CREATE TABLE` includes all columns, indexes, constraints, last auto increment, etc. However, I didn't bother pulling down any meta data like views, users, grants, etc. If that information matters to you, there are `SHOW VIEWS`, `SHOW GRANTS` or by pulling down tables from the `mysql` database.
Rob Van Dam