Uh oh!
There was an error while loading. Please reload this page.
fix(objectql): findData 返回真实 total/hasMore (#2212) - #2222
Merged
Conversation
findData previously returned stub pagination metadata — `total` equal to the current page's record count and `hasMore` hard-coded to false. The frontend grid therefore believed every result set fit on a single page and never requested records beyond the first batch (e.g. row #51+ unreachable). When a `limit` is present the response is one page, so `records.length` is the page size, not the match total. Run engine.count() over the same `where` to report the true total and derive `hasMore` from offset + page vs total. engine.count() only honors `where`, so for `search`/`distinct` queries (which it can't reproduce) fall back to a page-local estimate instead of a wrong total. Without a limit the full set is returned, so its length is the total. The aggregation/grouped branch had the same bug: it sliced to `limit` but reported the sliced length as the total with hasMore=false. It now reports the full grouped count as total and hasMore from whether the slice dropped any groups. Adds 5 pagination tests to protocol-data.test.ts (39/39 pass).
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 14 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
baozhoutao
commented
Jun 22, 2026
ContributorAuthor
前端配套 PR:objectstack-ai/objectui#1913(ObjectGrid 服务端分页 + DataTable manual pagination)。两者需配套合并。 |
Uh oh!
There was an error while loading. Please reload this page.
18 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes#2212
问题
ObjectStackProtocolImplementation.findData返回的分页元数据是占位值:total永远等于本页记录数,而非匹配总数hasMore恒为false因此前端表格认为结果集永远只有一页,永远不会请求第一批之后的记录(例如第 51 条及以后无法翻到)。REST 路由
/api/v1/data/:object直接把该结果原样返回给前端,问题就此暴露。修复
packages/objectql/src/protocol.tsfindData:limit时,响应是单页,records.length是页大小而非总数。对相同的where跑一次engine.count()得到真实total,并由offset + 本页长度 < total推导hasMore,实现真正的服务端分页。engine.count()只认where,无法复现search/distinct,这类查询退化为页内估计(满页即可能有更多)而非给出错误总数。不带limit时返回全量,长度即总数。limit却把 slice 后的长度当 total、hasMore=false。改为以完整分组数为total,hasMore取决于 slice 是否丢弃了分组。测试
packages/objectql/src/protocol-data.test.ts新增 5 个分页用例,39/39 全部通过。真机验证(天顺 EHR,同一 3125 行对象)
$skip