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