[Dbix-class] quote char works with sorting without breaking too much!

Ash Berlin ash at cpan.org
Wed Jun 21 17:01:12 CEST 2006


A. Pagaltzis wrote:
> * Jess Robinson <castaway at desert-island.demon.co.uk> [2006-06-21 11:15]:
>   
>> Ah, but this has fun with functions, which are currently supported as:
>>
>> order_by => [ { 'count' => '*'} ] .. etc
>>
>> At the last discussion of this, my end proposal was the following:
>>
>>   order by => [ [ 'name', 'asc'], 'lastname', [ { sum => 'age' }, 'desc' ] ]
>>
>> That is, the items in order by can be either:
>> 1) a plain fieldname, which will just get passed on
>> 2) an arraryref of fieldname and order direction
>> 3) an arraryref of functionhashref, and order direction
>> 4) a function hashref
>> 5) a scalar ref that will be passed on blind as before
>>     
>
> Ugh. I find that overloading the meaning of data structures based
> on type and level like you’re doing here always results in very
> hard to read code. And flat is better than nested.
>   
On the whole i'd agree with you here.
> This is one of the reasons I gave up on SQL::Abstract quite
> quickly when I tried to use it outside an ORM.
>
> For functions, I’d suggest supplying a scalar ref to be taken as
> literal SQL, just like the convention already used elsewhere.
>
> For ASC/DESC, I’d suggest just putting the qualifier inline into
> the list – ahead of the column it applies to because that’s
> easier to disambiguate:
>
>     order by => [ asc => 'name', 'lastname', desc => \'sum( age )' ]
>
> The only drawback is that column names that happen to be `asc` or
> `desc` need to be disambiguated by providing an explicit sort
> order. That doesn’t sound like a realworld concern to me, and
> even in those cases where it matters, the workaround isn’t
> exactly a hardship.
>
> Regards,
>   
Hows about:

order_by => [ asc => 'name', 'lastname', desc => {sum => [ 'age' ] } ]

(A cross between yours and what Jess had)

Ash





More information about the Dbix-class mailing list