I've worked with several over these over the years. I started with the ones that were integrated with DBI, like DBIx::Abstract. I eventually found it cumbersome that this approach left very little space for me to further tweak the SQL.

I was then drawn to SQL::Abstract for the simplicity of it-- just generating SQL and staying away from the database handle.

I had more flexibility, but eventually found SQL::Abstract's where clause generation too abstract and inflexible-- some kinds of AND/OR nesting just wasn't possible.

This brings me to my current recommendation, which is SQL::Interpolate. It allows you to express parts of SQL in Perlish ways, with a result that is natural looking and still open generating the rest of the SQL however you want.

No SQL statement has been too complex to use with SQL::Interpolate. Just to bring things full circle, I use it through DBIx::Interpolate, which simply passes the result on to DBI without getting the way further.

Still, it may not be a complete solution for what you are describing. Today I ran into a problem that perhaps like what you described. I needed to take a simple keyword field, split up the words, and generate some nested SQL to regular expression matches against several fields.

For that I wrote SQL::KeywordSearch, which I hope to put on CPAN soon. It can either generate $sql and @bind directly, or it can alternately generate a syntax that would plug directly into a larger SQL::Interpolate query.

If there's interest, I could prioritize wrapping up SQL::KeywordSearch for publishing. It's definitely a niche tool, but may at least be helpful as an example.

Note: I think SQL::Interpolate 0.40 may be released soon, with some improved syntax and docs.

I for one would be interested in seeing SQL::KeywordSearch as this sounds like an interesting project. When do you think you would have a beta version available?

Thanks
UnderMine

I'll try to publish this on CPAN in the next few days. Working code, docs and tests are already written. Just needs Polish and Publish. :)

Mark Stosberg

update: I've since published both SQL::Interp and SQL::KeywordSearch.

Mark Stosberg

I've seen some acclaim for SQL::Interpolate, though I've personally only tried it for a minor experiment. It won't figure out the joins for you -- you write the query in SQL and it just makes it easy to plug in the variable parts as perl data structures.

Coming from a DBA background I personally tend to do a minimal wrapping of DBI as a lot of these modules don't process transactions effectively and can be quite difficult to get to write optimised SQL code.

SQL::Interpolate does a mimimal amount of work for you. Allowing you to be helped by it(i.e. selects, inserts, updates especially) but still have control enough to bypass it during a transaction if you have to.

My opinion is you should always hand code a delete if you have to do it as these are too risky to leave to a code generator. However it is better to do a logical delete and then you can roll it back at any time.

Hope it helps
UnderMIne

I have data from a form that has to be turned into a select statement and it has too many options to write out every possibility, so there is no other option but to generate SQL to some degree. Since I'm only looking for something to create the actual SQL, not to handle any of the DBI work, transaction management will be up to me.

Since no-one has mentioned DBIx::Class and its powerful synergy with SQL::Abstract (a good SQL generator on its own), I now mention it. Jesse Vincent's DBIx::SearchBuilder is heavily used. And we can't forget DBIx::Recordset for a change in approach, though I am not happy with what happened to all my bugfixes to it. qw