On Mon, May 19, 2008 at 2:10 PM, luke saunders <[EMAIL PROTECTED]> 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: [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]
