phpmyadmin
phpmyadmin copied to clipboard
phpmyadmin
Filters are applied after pagination in list of tables within database
Describe the bug
See steps to reproduce
To Reproduce
Steps to reproduce the behavior:
- Go to https://demo.phpmyadmin.net/master-config/
- Click on a database that has at least 250 tables
So now you are in the Structure tab of the database you picked, and you are seeing the list of tables in this database. Because they are more than a lot, you see the first N in page 1.
- In the "Filters" input box next to "Containing the word:" enter a substring that you know is found in the names of several tables that are not all within the current page
For exampe, let's say you have tables named "table1", "table2", ... through "table400". You are at page 1, so you are seeing tables "table1" through "table125" or something.
Type "12" which means matching tables are "table12", "table112", "table120", ..., "table212", ... and several others
Expected behavior
The filter should be applied BEFORE pagination. So, ALL tables from the whole database that match with the filter should be selected and displayed, and THEN pagination should be applied if the matching tables are more than can fit in a page.
So in our example you should see all the tables mentioned above.
Observed behavior
(btw, the section "Observed behavior" is missing from the bug template)
The filter is applied AFTER pagination. So, you'll see only a subset of the first N tables that would fit within page 1 with no filter, and among those, those that match the filter.
So in our example you will only see "table12", "table112", "table120" through "table129" (I might be forgetting some) but not "table212", "table312" etc.
A filter working this way is completely useless. If it is by design, it's a wrong design. There's no question about that. Filter and then pagination is useful, pagination and then filter is useless. I hope don't need to explain that (if I need to explain that, there's no hope that you are able to fix that). Every widget I have ever seen that has pagination and filters works as I described in expected behavior, that is first filters and then pagination. Because it's the only useful and sensible way.
This, added to the fact (which is another separate bug) that there is no "show all" option for tables, makes it IMPOSSIBLE to have a list of all the tables that match a given filter without going page by page and repeating the search.
If there was a "show all" option, then that would mitigate the issue. Basically the filters would be useless within a single page but you could go to "show all" and then apply the filter.
Server configuration
whatever the demo has
Client configuration
- Browser: irrelevant, but Chrome
- Operating system: irrelevant but Ubuntu
Our filter is done in JS. This is why it is applied after pagination. @lem9 Could I have your comments on this feature request ?
Our filter is done in JS. This is why it is applied after pagination.
Yeah that is why it is done wrong. You should do an AJAX request. If you decided to do it entirely on the client side only with JS without doing an AJAX request, you took a wrong decision because that can't give you the correct behavior that should be expected.
This is not a feature request. This is a bug.
This is not a feature request. This is a bug.
To be clear it is a feature request. IMHO on this project a bug is something broken or a regression. I will classify this one as a feature request if no proof that I did work on another version is given. I hope you understand my maintainer point of view. And anyway we should focus on moving forward and not having pointless arguing about feature or bug ^^ ;)
To be clear it is a feature request. IMHO on this project a bug is something broken or a regression.
I hope we agree that not all bugs are regressions, so let's get that out of the way. Something can be broken since the beginning. I'm pretty sure this never worked before (or maybe there was a time when there was no pagination at all but there was a filter - actually, that would arguably make it a regression), but that's not relevant.
Now, BROKEN is something that doesn't behave correctly, and the current behavior is not correct.
If you have a reasoning to argue that the current behavior is sensible, then expose it.
So far the only argument has been "we implement this in a certain way, therefore the behavior is expected". That's a flawed reasoning. You choose an implementation based on the expected behavior, not the other way around. If you chose an implementation, and that implementation can only yield a behavior that is not the (or a) correct one, then you chose the wrong implementation.
If you disagree with me that the behavior is wrong, then I would like to hear your reasoning behind it, because I have NEVER seen a filter applied after pagination and I can't see how a user would ever expect that behavior. (actually, it's not wrong "because" I've never seen it, I've never seen it because it's wrong) (and ok, maybe It would be safer to say "rarely if ever" rather than "never". I'm pretty sure the same mistake has been made before and I might even have seen it and not remember it).
Anyway, it's not that important whether you want to call it a feature request or a bug, as long as it gets fixed, or as you like to say, "improved".
Anyway I agree with you that it could be "improved" because I also was frustrated about this particular behaviour last time I was searching for tables. And I will have to find the setting to show all tables in a mean time to workaround this issue
And I will have to find the setting to show all tables in a mean time to workaround this issue
Is there such a setting? Because actually I was intending to file another BUG report about the lack of a "show all" button (that I could respect - not agree - considering a feature request, but when an obviously necessary feature is missing, preventing you from doing a basic thing that the software is supposed to allow you to do, I call it a bug too)
https://docs.phpmyadmin.net/en/latest/config.html#cfg_MaxNavigationItems $cfg['MaxNavigationItems'] = 200;
Oh, ok, a system-wide configuration setting. No, that's not enough (but I'll certainly use that, thanks). The user needs to be able to choose to see all tables at once. There's a "show all" button for rows in a table, there's no excuse for not having one for tables in a database.
There's a "show all" button for rows in a table, there's no excuse for not having one for tables in a database.
You can file a feature request for that very usefull option
I agree with @php4fan, we should make an AJAX request everytime a user searches for a table name.
I agree with @php4fan, we should make an AJAX request everytime a user searches for a table name.
WON'T solve it! Also without userinputs Results can get Lost (like here - as reported as duplica of these issue: #16220) So, can you plese make a fix for PAGINATION (Pagination is the Problem, not the userimputs). Results can simly get lost and never reached (searched 3h in PhpMyAdmin and results never shownes becouse of These Pagination-Bug) Over SQL I was finally able to proove that the Data was in the DB, if not fixed, we need to deinstall phpMyAdmin (false tool is more worse than train team to SQL)...
- Is this issue specifically for the table filter on the database "Schema" tab, or the quick filter in general (e.g. the
.filter_rowfilter on the table browser)? - What was the original requirement spec for the feature? This would settle categorization of this and related issues as feature requests or bugs.
Attached is a test case that creates a DB with 277 tables. Table "zzzzz" is on the 2nd page and can be used as the filter target. Alternatively, "25" could be used as the filter, as there will be tables on both pages containing 25, so some of them will not be shown whichever page you're on.
I think we can improve this. For QA I think we could change the text to explicitly say that filter that page only. For master, we could create a new filter for all pages.
[...] For QA I think we could change the text to explicitly say that filter that page only. [...]
I was looking at the User Guide to document the behavior, but didn't see any appropriate sections. Is there someplace to discuss updates to the User Guide? Open an issue for the docs?
[...] For QA I think we could change the text to explicitly say that filter that page only. [...]
I was looking at the User Guide to document the behavior, but didn't see any appropriate sections. Is there someplace to discuss updates to the User Guide? Open an issue for the docs?
You can open an issue to discuss about that
Apologies if this was mentioned and I missed it but I just wanted to add that without the indication that you are looking at the filter results for page 1 instead of n it leads the user to believe that this is the complete set of results from the database. I came here to report this after typing my query string in the filter on page 1, finding 3 tables and believing that was the complete set. This was not the case and I needed to first navigate to page 2 and use the filter there in order to find what I was looking for. Even if the page indicator was kept, showing that these x results are the filtered set for page 1 that would prevent this kind of thing.
I fully agree. I was looking for a pretty critical table in Wordpress thinking it was missing and yet my SQL query was running fine. It took me a while to figure out the pagination. Please fix.
Thanks for phpMyAdmin. Yes, it would be very good feature. It could be in the pages selet, where you could choose "all". I have applied : https://docs.phpmyadmin.net/en/latest/config.html#cfg_MaxNavigationItems $cfg['MaxNavigationItems'] = 200; but it only applies to the left column, while I need it in the center one where you see the database tables and can apply orders, like truncate.
I found how to do it, $cfg['MaxTableList'] = 1000; But it would be nice to have it in the interface.
Can I just point out that this bug report is almost 4 years old and the functionality is still broken?
