[Oc-pm] June 20th Meeting Notes

[Douglas Wilson]

Ben Tilly wrote:
> 
>   my $example_sql = qq{
>     SELECT s.this
>       , s.that
>       , s.the_other
>     FROM foo f
>       , (} . indent($complex_subquery_sql) . qq{    ) s
>     WHERE f.some_key = s.some_key
>       AND f.some_field = 'some condition'
>   };
> 
> each of which has a clear and readable intent, and the result of which
> is nicely indented and is as legible as possible.  (ie not very.)

I'm happy as long as the statement is broken up by newlines
(single line SQL statements make for debugging fun...not!) :)

Though I like the style above, so maybe I'll just have to
get over my irrational fear of extra-indentation in multi-line
strings. :-)

When embedding SQL into indented blocks, I tend to use
the style at the bottom of this post:
http://www.perlmonks.org/?node_id=615032

Though when using that style in the past, I have at least once
misplaced a "," for a "." and ended up with a momentarily
mysterious "Odd number of hash elements" warning :-)

> 
> If you routinely wind up writing several hundred line SQL statements

I often find myself deconstructing 300 line SQL statements
rather than writing them, which was the entire reason for that
perlmonks thread. Then by the time I have them torn apart, figured
out and fixed, I'm too lazy to put them back together, so if
performance is reasonable, I'll leave it as is. It makes future
debugging easy, like when trying to figure out why certain data
doesn't make it through the entire pipeline, as I can eliminate joins
by commenting out one line at a time.

The biggest drawback with the framework in that thread is that you
can't order by arbitrary columns :-(  So you have to pipe it through
some other process if you want to order by anything other than columns
in the outermost SQL statement (to columns statements contiguously inward).

Well, I should be able to make the next meeting...

-Doug