Handling page underflow

[alanoliveira]

Currently there is the Overflow module and OverflowError to handle cases when the requested page is greater then the last page.
I suggest to deprecate it and create a Outbound and OutboundError to also handle when page is less then 1.

I know I can override pagy_get_page, or create a PagyOverride, but I think it is a common problem so it would be nice to be in the lib.

[ddnexus]

Then why not "UnderflowError"? 🙂

Not sure we need one, however I can think how it would fit into the soon to release v10.

[alanoliveira]

Sure!
I suggested "Outbound" because I think that whenever someone wants one part, they'll also want the other, but it's probably better to keep them separate.
Thank you

[ddnexus]

There is a big difference between overflow and underflow... Overflow is a likely condition that means nothing wrong... it's just a glitch of the offset pagination technique that denotes only a change in the database. As long as the page is a positive integer, it's all OK with pagy and its use... however it's a fatal situation for the current instance, that requires a decision about how to proceed .

The underflow instead is a generic bad use of pagy... like passing a string instead of a number, or anything else wrong with the variables. Why should it have a special treatment? What's different between being a negative number or a string? And BTW, the variable error, will show you what was the value, so why do we need another exception?

[alanoliveira]

We don't need, or at least I don't
For my use case

pagy/gem/lib/pagy/backend.rb

Lines 39 to 42 in d70e443

	def pagy_get_page(vars, force_integer: true)
	page = params[vars[:page_param] || DEFAULT[:page_param]]
	force_integer ? (page || 1).to_i : page
	end

    def pagy_get_page(vars, force_integer: true)
      page = params[vars[:page_param] || DEFAULT[:page_param]]
-    force_integer ? (page || 1).to_i : page
+    force_integer ? [ page.to_i, 1 ].max : page
    end

is enough

[ddnexus]

That's nice! I like it, but ideally, it's better to raise an exception. This approach can mask more serious underlying issues, making them harder to diagnose. For example, figuring out the root cause of a repeating 'Page 1' would be more challenging compared to a clear exception that pinpoints the problem.

If you use that in your code, you are aware of it. However, if Pagy handles the issue internally, it might be doing so 'behind your back,' potentially concealing critical problems. 😈