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

[Drew Taylor]

On Mon, May 19, 2008 at 2:10 PM, luke saunders <luke.saunders at gmail.com> wrote:
>
> 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?

I agree that a system() call feels a little wrong, but IMHO in the end
that's what it's going to come down to because there are no perl hooks
for pg_dump, mysqldump, etc. And honestly, I'm lazy and have little
practical experience with databases other than pg & mysql so my
ability to contribute a wrapper for other database dump mechanisms is
NULL. :-)

My initial reaction is to allow the user to specify two things: 1)
path to dump binary 2) arguments to pass to said binary. The reason
for 2 params is to increase flexibility in case you want to dump in
multiple ways (you never know..). The args could be a literal string,
or maybe even an sprintf-compatible string but that feels like a
security hole waiting to be found.

>> 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.

done

>> 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).

I played with several ideas before going with this one, but automatic
parsing is always going to fall down somewhere. Basic DDL will
generally be fine, but IMHO anything complicated like stored
procedures, etc will always be difficult for a non-database-native
parser to grok. If we give the user the ability to avoid those edge
cases, we'll save people time _before_ they get frustrated trying to
work around it.

That said, it's not particularly pretty to look at so I'm definitely
open to other approaches.

Drew
-- 
----------------------------------------------------------------
 Drew Taylor                 *  Web development & consulting
 Email: drew at drewtaylor.com  *  Site implementation & hosting
 Web  : www.drewtaylor.com   *  perl/mod_perl/DBI/mysql/postgres
 ----------------------------------------------------------------