[DBIx-Class-Devel] OffsetFetchNext Support for SQL Server 2012

[Peter Rabbitson]

On Sun, Jul 21, 2013 at 09:22:20AM +0200, Alexander Hartmaier wrote:
> For me it makes sense to see in version control what lead to a piece of
> code, but riba likes squashing multiple commits into a single commit.

I routinely get to look back through the years to see which line came 
from which general commit. Blaming (and bisecting) with a ton of commits 
that serve nothing more than a historic purpose is *very* hard. Thus 
squashing will be kept towards the reasonable maximum.

> Imho paging without a defined order makes not a lot of sense because the
> returned resultset is unstable and the same rows might be included in
> multiple pages.

Yes, it is unstable and that is fine. The use case you ar emissing is 
not paging but limiting (say the first X). But you have another point 
here, see below.

> I had such a problem with the Oracle pagination two years ago:
> https://github.com/dbsrgits/dbix-class/commit/6a6394f19f31dbc44cb5382d241890555e8cebd5

Which you only detected (and cared about) because you did supply an 
order. If you had a resultset and was asking for "N unordered rows" 
repeatedly and were getting definite results - I doubt you would 
complain.

> 
> Shouldn't DBIC warn(or even die?) if pagination of a non-ordered resultset
> was requested?

Yes and no. Warning on a simple limit is a no-go. However there is no 
way to reliably do a limit with offset (i.e. non-first page) since the 
offset can notbe stabilized. Warning (carp_unique)on *that* condition 
only is warranted. Please add something at the end of the resolution 
stage (this is the point where it should be, not in the sqlmaker, and it 
only should look at a defined offset, nothing else): 
https://github.com/dbsrgits/dbix-class/blob/master/lib/DBIx/Class/ResultSet.pm#L3653