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

[luke saunders]

On Mon, May 19, 2008 at 4:32 PM, Drew Taylor <taylor.andrew.j at gmail.com> wrote:
> 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. :-)
>

I suppose the idea would be for you to do the pg one and either me or
you to do the mysql one then if anyone wants anything else they'll
just have to make it. but they'll be tiny so no real problem.

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

if they pass the args then they'll probably have to pass the
connection details which is repetition and also not very pretty. my
vote would be for passing just the path and having the DB specific
code format the command itself.

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

Yeah, you're probably right. Let's go with what you propose.