[Dbix-class] possible optimization bug in 0.08250

[Peter Rabbitson]

On Sun, Jun 02, 2013 at 03:55:10PM +0200, Alexander Hartmaier wrote:
> One of my result classes has a rel ordered by a related column:
> 
> __PACKAGE__->has_many(
>     "entries",
>     "NAC::Model::DBIC::Table::Patch_Interface",
>     'fk_patch_request',
>     { order_by => 'row_index' },
> );

This actually never worked - it is the result of RT#63709 [1] 

> The following code used to sort by entries.row_index

Please tripple check that it indeed ordered by row_index. The old 
codebase would order by the far side of a relationship (extremely 
inefficient) just so it can do some sort of sane collapse. The order_by 
was added implicitly however, the order_by from the has_many was likely 
never utilized.

So all in all - there is a bug, but it very very likely is not where you 
think it is. Please find out what happens in reality.

Cheers

[1] https://rt.cpan.org/Public/Bug/Display.html?id=63709

> my $request = $rs->find( $id, { prefetch => [
>             'rel_accept',       'rel_req_status',
>             'rel_req_customer', 'view_version',
>             'entries',
>         ],
>     });
> 
> This is the resulting SQL. It does an order by but on the primary key of the result class:

Fun fact - if you did $request->all, there would be no order_by *AT 
ALL*, since the only reason we need an order is so that $rs->next will 
work sensibly.