On Wed, Jun 18, 2008 at 2:18 PM, Ovid <[EMAIL PROTECTED]> wrote:
> --- Drew Taylor <[EMAIL PROTECTED]> wrote:
>
>> Luke and I have discussed briefly how we can encapsulate this
>> behavior, but we haven't gone further than that. Patches & ideas
>> welcome! :-)
>
> This is conceptually similar to what I need to do, but as mentioned
> previously, I want that DDL to only be the data I'm loading for the
> fixtures, not the entire database + static data (which already exists
> by the time I need to load the fixtures.
The key point is that you use D::C::Fixtures to specify the _subset_
of the whole database for your test fixtures, and then subsequent
population operations only load that subset. In my case, I only have a
half dozen resorts and hotels for fixtures instead of the hundreds -
plus all their associated availability and pricing information - that
exist in production. My pg_dump file is 15k lines long and takes ~10
seconds to import on my iMac.
> So I guess this all goes back to my original question: when I'm
> running DBIx::Class, is there any way I can trap the SQL and bind
> parameters used so I can potentially cache them?
You can dump the queries and the bind values using $ENV{DBIC_TRACE}. I
suppose you could redirect that to a separate file somehow and parse
it from there. That is pushing the extent of my DBIC internals
knowledge, so someone else will have to chime in.
Drew
--
----------------------------------------------------------------
Drew Taylor * Web development & consulting
Email: [EMAIL PROTECTED] * Site implementation & hosting
Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres
----------------------------------------------------------------
_______________________________________________
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]
