On 6/10/07, Nilson Santos Figueiredo Junior <[EMAIL PROTECTED]> wrote:
On 6/7/07, Brandon Black <[EMAIL PROTECTED]> 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
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
