Unexpected behavior on negative page number

[bart-degreed]

It doesn't seem right that a negative page number reverses the sort order.

I believe a better syntax for reversing the sort order would be: ?sort=- (without any attribute). This can be combined with attributes: ?sort=lastname,-age,-

With that in place, we should change the meaning of a negative page number, to indicate (n) pages back from the last one. This requires to know the number of total pages, so it should fail with an error in case options.IncludeTotalRecordCount is set to false.

[maurei]

related: #643

[maurei]

From #643 :

Backward paging would start at the end. It would field

• for the first backward page (page[number]=-1) the set { n } ... { n-9 }, and
• for the third backward page (-3) the set { n-20 } ... { n-29 }

Agreed: this does not make sense. Should be

• { n-9 } ... { n }
• { n-29 } ... { n-20 }

[bart-degreed]

On second thought, I believe that reversing the sort order of an unordered set is not a very useful feature to have. Users can always sort descending by ID if desired.

Making negative page numbers mean 'from end' has some drawbacks:

• It could only ever work top-level
• If -1 means "1 page from the end" then there is no way to access the last page using negative notation. On the other hand, if -1 means the last page, it may look counter-intuitive.
• options.IncludeTotalRecordCount controls whether response metadata is added that shows the count. That we need to retrieve the could separately for that is only a side effect, so this option does not match the scenario. Instead we should an option AllowPagingFromEnd that, when enabled, retrieves the count and throws otherwise.

For now, I intend to remove support for negative page numbers entirely. When the need for page-from-end comes up, we can revisit how to best implement that.