[Dbix-class] DBIx::Class::Fixtures suggestions/patches

luke saunders luke.saunders at gmail.com
Mon May 19 14:10:21 BST 2008


On Mon, May 19, 2008 at 10:11 AM, Drew Taylor <taylor.andrew.j at gmail.com> wrote:
> (warning long post)
>
> I have written a Fixtures wrapper for my particular workflow for use
> at $work, along with some customizations to D::C::Fixtures and wanted
> to get opinions about pushing them to svn. To get a big performance
> boost for population I'm now using the following procedure when
> creating a dump:
>
> 1) Dump from source database using Fixtures
> 2) Populate dump into fixtures database
> 3) Run pg_dump from fixtures database into separate dump file
> 4) Delete fixtures dump dir (actually using File::Temp::tempdir)
>
>...
>
> And population goes like:
>
> 1) clear fixtures database
> 2) import pg_dump file
> 3) run post_ddl bits
>
>...
>
> When I populate I just read in the pg_dump file, resulting in test
> runs in 1/4 of the time (12-15 seconds to populate & run a test file
> vs 45 seconds doing populate via DBIx::Class::Fixtures::populate().
> This is not a criticism of Fixtures, because I love the ability to
> easily specify what database tables/rows to dump. I was wondering
> about creating an alternate set of dump/populate methods which would
> encapsulate this workflow, but be db agnostic. It dramatically sped up
> my tests, so much so that I'm likely to run them more often now. :-)
>

Yes, I did something very similar to this for my project using
mysqldump and have also been thinking about how to make it an addon to
DBIx::Class::Fixtures. I just haven't figured out the best way to do
so since the dump command is not only database specific but also
system specific.

My thinking is that either we make the path to the dump executable
configurable and then have DB specific modules which build the system
command, or we make the whole dump command configurable. The former
seems a bit neater to me as then there's no repetition of connection
details etc. Using a system command still feels a bit wrong though.

Did you have a better idea?

> Some other changes I've made locally:
>
> 1. Move the post_ddl bits into a separate method. I then call this
> method from my wrapper. Diff against latest 1.001/trunk:
> ...

Looks fine to me. Feel free to commit.

> 2. Support for "grouping" in ddl files. I ran into a major problem
> where some of my ddl files had stored procedures with semicolons. The
> original _read_sql(), while clever and simple, would break horribly
> with the embedded semicolons in my procedures. I added (crude) support
> for grouping to avoid this problem. The DDL has comments which trigger
> the feature.
>
> ...

I see the problem but I'm wondering if there's an easier solution,
like just splitting on semicolon only if it's at the end of a line or
something (though this is flawed).

Let's see if anyone else has a better idea and I'll have a think. If
nothing better comes up we'll go with your idea.

Cheers,
Luke.



More information about the DBIx-Class mailing list