tju-yxq opened a new issue, #2426:
URL: https://github.com/apache/rocketmq-dashboard/issues/2426
## Problem
The data-source inventory is still returned as an unbounded list and
rendered as an unpaginated table.
Backend:
```java
List<DataSourceVO> findAllDataSources();
```
```java
dataSourceMapper.selectList(new
QueryWrapper<RmqDataSource>().orderByAsc("id"))
```
API:
```java
@GetMapping("/datasources")
public Result<List<DataSourceVO>> listDataSources()
```
Frontend:
```ts
listDataSources()
.then((sources) => setDataSources(sources));
```
```tsx
<Table ... pagination={false} />
```
This leaves several operational gaps:
- the Settings page loads every data source into memory;
- there is no server-authoritative name search;
- there is no type filter;
- the user cannot page through a large inventory;
- the API has no total count, so the UI cannot distinguish a bounded page
from the complete inventory;
- ordering is currently by insertion id, not by recent modification, so a
newly updated data source can remain buried on a later page;
- create/update/delete only mutate a local unbounded array rather than
refreshing the canonical page.
The database model already has `gmt_create` and `gmt_modified`, so no schema
migration is required to establish a stable update-time order.
## Expected behavior
Implement the established bounded inventory contract for data sources:
- `GET /api/settings/datasources` should return `PageResult<DataSourceVO>`;
- accept:
- `page`, default `1`;
- `pageSize`, default `20`, bounded by `100`;
- `search`, matched against data-source name;
- `type`, matched exactly after normalization;
- filtering and pagination should occur in the repository query, not by
slicing a full in-memory list;
- ordering should be `gmt_modified DESC, id DESC` for stable page boundaries;
- invalid page/pageSize should return HTTP 400;
- the frontend should render:
- a debounced name search;
- a type filter;
- server-side pagination with 20/50/100 options;
- server-provided total count;
- request sequencing so stale filter responses cannot overwrite newer
results;
- filter changes should reset to page 1;
- create/update/delete should refresh the canonical server page instead of
only patching an unbounded local list.
## Compatibility considerations
The current endpoint returns `List<DataSourceVO>`. A direct breaking change
may affect existing API consumers. The implementation should either:
1. preserve the existing endpoint and add a clearly separated paginated
endpoint, or
2. document and intentionally migrate the endpoint to `PageResult` if
maintainers prefer the established inventory contract.
The proposal should state the selected compatibility strategy explicitly.
## Tests
Backend:
- default page/pageSize;
- page/pageSize validation;
- name and type filtering before paging;
- stable `gmt_modified DESC, id DESC` ordering across page boundaries;
- filtered total correctness;
- controller query binding and response contract.
Frontend:
- initial load requests page 1 with page size 20;
- search/type filters reset to page 1 and send both parameters;
- pagination changes send page and page size;
- stale response suppression;
- create/update/delete refresh the canonical server page;
- existing credential redaction and connection-test behavior remains intact.
## Value / expected size
This is a real operational scalability/usability gap and is tracked as
#2298. The backend contract, repository query, service validation, controller
binding, frontend API, filter UI, pagination UI, request sequencing, and
mutation refresh naturally require more than 100 lines of production code.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
