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