17 Dec
2007
17 Dec
'07
1:07 p.m.
Sebastian Mendel a écrit :
Marc Delisle schrieb:
It won't hurt, but I tend to respect his explicit LIMIT for consistency.
Sebastian Mendel a écrit :
if he is not interested in seeing other rows, pagination will not hurt? Marc Delisle schrieb:
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.
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 !?
(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?
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.
17 Dec
17 Dec
1:53 p.m.
New subject: [Phpmyadmin-devel] about explicit LIMIT
Marc Delisle schrieb:
Sebastian Mendel a écrit :
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
Marc Delisle schrieb:
It won't hurt, but I tend to respect his explicit LIMIT for consistency.
Sebastian Mendel a écrit :
if he is not interested in seeing
other rows, pagination will not hurt? 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? 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.
2:05 p.m.
New subject: [Phpmyadmin-devel] about explicit LIMIT
Sebastian Mendel a écrit :
Marc Delisle schrieb:
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).
Sebastian Mendel a écrit :
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?
Marc Delisle schrieb:
It won't hurt, but I tend to respect his
explicit LIMIT for consistency.
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? 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. 
2:17 p.m.
New subject: [Phpmyadmin-devel] about explicit LIMIT
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
18 Dec
18 Dec
3:36 p.m.
New subject: [Phpmyadmin-devel] about explicit LIMIT
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Some users might expect to see the same rows when resorting. However, in
command-line mysql, you really get different rows in this case.
Sebastian Mendel a écrit :
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?
Marc Delisle schrieb:
It won't hurt, but I tend to respect his
explicit LIMIT for consistency.
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? 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.
6108
days inactive
6109
days old
4 comments
3 participants
participants (3)
-
cand. inf. Alexander M. Turek -
Marc Delisle -
Sebastian Mendel