phpmyadmin / phpmyadmin/phpmyadmin

Filters are applied after pagination in list of tables within database

Open
#16,084 21 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bug Enhancement help wanted
Dominant language
PHP
Stars
7.9k
Forks
3.6k
Avg merge
4d 18h
Merged PRs (30d)
36

Description

Describe the bug

See steps to reproduce

To Reproduce

Steps to reproduce the behavior:

  1. Go to https://demo.phpmyadmin.net/master-config/
  2. 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.

  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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the issue from a database's Structure tab using the Filters input and a database with more than 250 tables. Trace how the table list applies filtering and pagination, then verify that all matching tables are selected before page limits are applied. Done means matching tables from later pages appear in the paginated results.

Written by the indexing model from the issue text.

Assessment

Tech stack
mariadb, mysql, php
Domain
databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.