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.
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?
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).
Hi Sebastian & list,
Sebastian Mendel schrieb:
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, but semi-smart auto-pagination won't help either. For MySQL >= 4.1 we can fix that by surrounding the users original query with a SELECT that adds the clauses we need for pagination and reordering and this is probably the way to go for at least PMA 3.0. Without subselects, I don't see a way to fix that, right now.
Of course, the whole discussion appears ridiculous when thinking about limiting a query to 3 or 5 result rows. But when talking about databases, we have to think about the ones that have a couple of more records and about queries that return a couple of more rows. Limiting a query to 500 or 1000 rows is ihmo not a stupid thing to do. :-)
The intention of LIMIT is not pagination but a kind of selection. This is why I would not expect an appended LIMIT to affect phpMyAdmin's pagination behavior. phpMyAdmin just uses LIMIT for pagination, but it's rather a hack, since we do not have something like server-side results with pointers that we can keep alive during multiple requests of a session. We should respect the purpose of the keyword, imho.
On the other hand, buttons to remove certain parts of the outermost query (like LIMIT, ORDER BY) - as long as the interface does not get too bloated - would be fine for me. What do you think?
Regards,
Alexander
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?
Some users might expect to see the same rows when resorting. However, in command-line mysql, you really get different rows in this case.
-
cand. inf. Alexander M. Turek -
Marc Delisle -
Sebastian Mendel