Sebastian Mendel a écrit :
> Marc Delisle schrieb:
>> Sebastian Mendel a écrit :
>>> Marc Delisle schrieb:
>>>> 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.
if we would use a function for locale strings we could automatically add
<span xml:lang="en" dir="ltr"></span> to not translated strings, avoiding
display problems in RTL languages, and problems with screen readers
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?
(1) To be able to move thru the entire table
(2) or just thru the result set he chose in his LIMIT clause?
Reading this bug report
the user expects (1). I am not sure but I tend to say (2) because of the
Of course in this bug report there are real bugs to solve but to
implement the current solution we have to decide about this issue first.
Welcome to phpMyAdmin 2.11.3, a bugfix-only version.
- patch #1818389 to remove a notice (failed to flush buffer)
- patch #1821154, HTTP authentication: fix auth working
- wrong default charset in case of broken session
- bug #1824506 [profiling] Profile command repeated on
older MySQL servers
- bug #1825172 [export] Exporting and functions
- bug #1817224 [import] Incorrect detection of file_uploads
in some cases
- bug #1777249 [display] Do not underline links in left panel
- bug #1826022 [privileges] unable to add user (MySQL 3.23)
since PMA 2.11.2
- bug #1823045 [import] Error importing file with lowercase
- bug #1828913 [structure] Can't set FULLTEXT index on CHAR column
- bug #1804081 [export] export on server doesn't obey
- bug #1789988 [display] space before SHOW COLUMNS
- bug #1831646 [table creation] Error in CREATE TABLE with multiple
primary keys and AUTO_INCREMENT
- [display] Division by zero when showing all records (page selector)
- bug #1828265 [privileges] No weird characters in generated password
- bug #1759194 [import] open_basedir warning
- bug #1793948 [parser] ROW_FORMAT incorrectly parsed
- undefined PMA_MYSQL_INT_VERSION when no default server is set
- bug #1763343 [session] Behavior with session.auto_start enabled
+ [lang] Hungarian update
- patch #1837691 [query window] js errors
- patch #1839052 [lang] catalan not in UTF-8
- patch #1838626 [GUI] Login interface broken on Konqueror
Download from http://www.phpmyadmin.net
Marc Delisle, for the team