[Dbix-class] DBIx::Class 0.07999_05 (aka 0.08 RC2) released

[Brandon Black]

On 6/10/07, Nilson Santos Figueiredo Junior <acid06 at gmail.com> wrote:
> On 6/7/07, Brandon Black <blblack at gmail.com> wrote:
> > We have a second release candidate now after the (much appreciated)
> > feedback from the first one.  Most of the issues were related to
> > module dependency issues in the build/test process rather than real
> > code regressions, so it's looking pretty good so far.  Please give
> > this one a good testing too.  While you're waiting for CPAN to get a
> > copy, you can fetch it directly from:
>
> I still got one failing test case for a bug I've first reported back
> in December.
> Paging is still broken for chained resultsets.
>
> I'm resending the patch to 67pager.t which makes this issue pop up
> along with this message.
>

"order by" and limit are tightly related in SQL, and afaik you can
only have one of each.  For your simple case, it's easy to say that:

$rs->search({}, { rows => 2, page => 2})->search(undef, { order_by => 'title'})

should be interpreted as:

ORDER BY title LIMIT 2 OFFSET 2

And perhaps this:

$rs->search({}, { rows => 7, page => 3, order_by => 'title'
})->search(undef, { rows => 2, page => 2, order_by => 'artist' })

should be interpreted as:

ORDER BY title, artist LIMIT 2 OFFSET 16

So basically, I'm interpreting it as if it were implemented with a
true subselect, but then optimizing it down to a single set of
orderby/limit/offset (which afaics, is always mathematically possible
and correct).  My intepretation of how to progressively apply
rows/page/order_by means that some sets of inputs return nonsensical
output that clearly isn't what the requestor wants.  For instance:

$rs->search({}, { rows => 3, page => 2, order_by => 'title'
})->search(undef, { rows => 2, page => 5, order_by => 'artist' })

Would be an empty set (no point in even executing the SQL), as the
first search limits to a total of 3 records, and the second search
wants to skip down 8 records within that before fetching anything.
Probably they intended for the second rows/page to override the first.
 We'll just have to document well whatever direction we go with
interpreting these.

Is that about what you mean?

Personally, I think it's a bit late in the cycle to try to add support
for this, as it isn't a regression against 0.07, and adding support
for this feature will undoubtedly be complex enough to introduce new
bugs.  I would recommend waiting until 0.08 is pushed, but I'm open to
other suggestions :)

-- Brandon