[Dbix-class] Caching DBIx-Class Fixtures

[luke saunders]

On Wed, Jun 18, 2008 at 2:36 PM, Ovid <publiustemp-dbic at yahoo.com> wrote:
> --- luke saunders <luke.saunders at gmail.com> 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.