[Bug] TableSelector silently truncates table list when DB has more tables than API page limit

[MelikHajlawi]

Bug description

The useTables hook returns a hasMore flag that is true when the backend
has more tables than the current page response includes:

hasMore: json.count > json.result.length

However, this flag is never consumed by TableSelector or any other UI component.
When a database has more tables than the API page limit, users see a truncated list
with no warning, no count indicator, and no way to know that tables are missing.

Steps to reproduce

1. Connect a database schema with 100+ tables
2. Open SQL Lab, select that database and schema
3. Observe the table dropdown — there is no indicator that the list is truncated

Expected behavior

A helper message should appear below the table selector informing users that the
list is truncated, e.g. "Some tables are not shown. Refine your search."

Files

• superset-frontend/src/hooks/apiResources/tables.ts — hasMore is computed
• superset-frontend/src/components/TableSelector/index.tsx — hasMore never used

### Screenshots/recordings

_No response_

### Superset version

master / latest-dev

### Python version

3.9

### Node version

16

### Browser

Chrome

### Additional context

_No response_

### Checklist

- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

This is a valid observation. The hasMore flag is indeed computed in the useTables hook:

transformResponse: ({ json }: QueryResponse) => ({
  options: json.result,
  hasMore: json.count > json.result.length,
}),

And returned as part of the hook's Data type [1], but the TableSelector component only destructures currentData, isFetching, and refetch — never hasMore [2].

That said, there's an important nuance: the backend currently returns all tables/views for a schema without pagination [3]. There's even a TODO in the code acknowledging this:

// TODO: Would be nice to add pagination in a follow-up. Needs endpoint changes.

So in practice, hasMore would only be true if the backend did implement pagination — which it currently doesn't. The truncation scenario you describe would require the backend to actually impose a page limit on the tables endpoint. Right now, all tables for a given schema are returned in a single response.

A fix here would involve two pieces:

1. Backend: Add pagination support to the tables endpoint (the TODO already calls this out)
2. Frontend: Consume hasMore in TableSelector to show a message like "Some tables are not shown. Refine your search." or implement infinite scroll/load-more

If you'd like to contribute a PR for the frontend piece (consuming hasMore and showing a helper message), that would be useful groundwork for when backend pagination is eventually added.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.