[Dbix-class] Re: [OT][ANNOUNCE] SQL Generation with SQL::DB

Emanuele Zeppieri ema_zep at libero.it
Mon Sep 10 17:54:35 GMT 2007

A. Pagaltzis wrote:

> Hi Emanuele,
> * Emanuele Zeppieri <ema_zep at libero.it> [2007-09-07 13:25]:
>> A. Pagaltzis wrote:
>>> * Emanuele Zeppieri <ema_zep at libero.it> [2007-09-07 11:15]:
>>>> Mark Lawrence wrote:
>>>>> If that is so, then you are asking how the following is
>>>>> evaluated?
>>>>>   ($track->length > 248) & ! ($cd->year < 1997)
>>>> No, I'm asking how it could be *built* by code without string
>>>> concatenations/interpolations.
>>> Uh. They’re Perl expressions. Don’t you know how to write
>>> conditionally executed Perl expressions? What are you doing on
>>> this list? :-)
>>>    use List::Util qw( reduce );
>>>    my @cond;
>>>    # in real code the following stuff would be more systematic;
>>>    # this is just to demonstrate the principle
>>>    if ( $min_track_length ) {
>>>        push @cond, $track->length > $min_track_length;
>>>    }
>>>    if ( $max_year ) {
>>>        push @cond, $cd->year < $max_year;
>>>    }
>>>    my @where = @cond
>>>        ? ( where => reduce { $a & $b } @cond )
>>>        : ();
>> ROTFL! :-)
>> Not only a bunch of reduce()'s are mainteinibility-wise even
>> worse than string concatenations
> News to me.
> I can only see one `reduce` in that code, btw.

Yes, indeed it remains a mistery why you thought that the "&" operator 
required a reduce while the ">" and the "<" operators didn't :-)

> But anyway, `reduce` shouldn’t be necessary here, the SQL::DB API
> could do that work internally. But I’ve already said that.

It was only you that have the brilliant idea to resort to an 
(unnecessary) reduce, do you remember that pal? It happened only few 
hours ago :-)

>> (did you understand that also subexpressions like:
>> "$track->length > $min_track_length"
>> and
>> "$track->length > $min_track_length"
>> must be built *dinamically*, from arbitrarly user data, not
>> statically in the code as you did in your example? :-)
> How is my code not building them dynamically? If
> $min_track_length has no value, then that condition is not added
> to the code. Please explain to me how your SQLA data structure
> manipulation code is somehow more dynamical than that.

The above mentioned relational expressions are dynamic *only* as long as 
you live in a little contrived universe where the $track->length field 
can only be compared through the ">" operator and the $cd->year field 
only through "<".

> Actually, go ahead: post some magic dynamical SQLA query builder
> code that I can’t translate to SQL::DB. Let’s watch me fail.

Examples in points 2 and 4 in my response to Mark, please.

Anyway don't cheat: I've never said that you can't do them with SQL::DB, 
I just said that It'll require more code.

>> but, if you perform a sequence of reduce()'s, you should even
>> find the correct order to honor the operators precedences.
> `reduce` folds left to right. What things are more to the left
> and which are more to the right in the array will depend on the
> order in which I put them in the array.
> Funnily enough, that means I have to pay attention to exactly the
> same things as I would have had to if I were building SQLA query
> data structures.
>> Basically, you're rewriting an SQl parser, thus fully bypassing
>> the SQL::DB expression parser (and reimplementing it in your
>> code, congratulations! :-)
> Point me to which part of my code does any parsing.

Indeed you didn't do any parsing, which means that you cannot handle 
more dynamic cases (as the ones showed in my examples in points 3 and 4).

> Point me to which part of my code is conceptually different from
> what an SQLA data structure builder snippet does.
>> You did consider that, right?
> Why should I? It’s wrong.

Don't mark as wrong something you are not able to understand.

>> So, who should reconsider his presence on this list? (as well
>> as in the programming world in general :-)
> Oh crap, you’re right. I should pack my bags and leave. :-)

Just for a vacation.
It could even relax you ;-)


More information about the DBIx-Class mailing list