Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Hi, I am seeking your input about the following issue. Normally if a user just browses a table, he can use the navigation << < > >> and "Page number" to move thru the table. LIMIT clause is generated accordingly.
Now if a user typed a LIMIT clause, what should he expect?
seeing what he queried, if he wrote LIMIT 0,2 we should show two lines per page
(1) To be able to move thru the entire table (2) or just thru the result set he chose in his LIMIT clause?
table = result !?
No sure I understand your question, but the result set from a query is different than showing the plain table. See the other answer by Alexander.
(1) with his limit as initial rows per page
I thought about this. We could use his "LIMIT x,y" to fill the "Show y rows starting with record #x". But I'm still not sure: why did the user put an explicit LIMIT? To limit the initial display, or because he's really not interested in seeing other rows?
if he is not interested in seeing other rows, pagination will not hurt?
It won't hurt, but I tend to respect his explicit LIMIT for consistency.
the problem is, if we omit all rows not in his LIMIT and do not display pagination, and he re-sorts the result by clicking on column he will get completely different rows, cause the sorting is not done on the result, but on the on the source of the result before the LIMIT - i think this will confuse even more, or?
Starting with 2.11.4, the sorting on column headers is done on the results, respecting an explicit LIMIT.
having a query like:
SELECT * FROM `tab` ORDER BY `a` LIMIT 3
with more than 3 rows in `tab`
will result in 3 completely different rows when clicking on column `b` in the result table
is this what the user expects?
Probably not! I had only tested without an initial ORDER BY clause. But now I don't know what to do :) (apart from using a subquery).