On Wed, Jun 18, 2008 at 2:36 PM, Ovid <[EMAIL PROTECTED]> wrote: > --- luke saunders <[EMAIL PROTECTED]> wrote: > >> Ditching the database and then recreating it for each test is the >> right thing to do in the general case since previous tests might have >> dropped tables, deleted/created rows and so on which would affect >> subsequent tests. I see from the article that you have a >> static/dynamic split for your tables so that the static tables are >> created once then left untouched for all tests, but when/how do you >> refresh the dynamic ones? > > It's simple. Each test fetches a schema object. That's when the > dynamic tables are refreshed by truncating them. The fixtures are then > loaded. > > This approach is not perfect, but the trade off was fantastic: we were > able to actually use our test suite again. In practice, we've not > actually had problems with this tactic.
I don't quite understand what 'refresh by truncating them' means, but anyway. If you had a MySQL dump of the DDL and the static data which was imported once at the start of the test run, then some other kind of SQL dump which just contained the dynamic data and was run for each test (or whenever you needed to refresh), would that be enough? If you generated these dumps whenever the fixtures files were changed, then you wouldn't need to do the MD5/SQL cache thing, right? >> I think the main thing is, if you find the ability of >> DBIx::Class::Fixtures to specify what data should be included in each >> fixture set desirable then you can just customise the rest to suit >> your needs. > > I'll have to read through the docs more carefully. I didn't really > understand them :) Then please do send a doc patch should you get your head around it, or at least point out what's confusing. > So is there no programmatic way of getting the SQL and bind params that > DBIx::Class generates? We've needed this functionality a few times and > not just for this. In addition to what Dagfinn said, I _think_ that the upcoming SQL::Abstract refactor will make it easier to get at the generated SQL and so until then it's a bit fiddly. _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
