[Feature Request] `groupBy` and `aggregate` should support `include`
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 15/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- typescript
調査の方向性
The issue points to no files, so begin at the query engine that compiles groupBy/aggregate calls and compare it with how include is resolved for find queries; that pairing shows where join logic would be added. Then read the policy-enforcement layer to see how include results are filtered, since the request requires access policies to be respected. Done means groupBy/aggregate accept include, related fields come back in the result, and tests cover both policy-restricted and unrestricted joins.
索引モデルが issue の本文から書いたものです。
説明
Is your feature request related to a problem? Please describe.
When using the query API groupBy and aggregate currently operate only on fields of the base model. There is no way to join related models using include or similar semantics. This becomes a problem when aggregating records by a value that lives on a related table and is not the primary key. In practice this means I can group by a foreign key id but then must perform an additional query to resolve meaningful fields like a symbol or code from the related table, which adds extra round trips and complexity.
Describe the solution you'd like
Extend groupBy and aggregate to support include so that related models can be joined as part of the aggregation query. This would allow grouping or aggregating based on fields from related tables and returning those related fields directly in the result set. Conceptually this would mirror how include works for find queries while still respecting ZenStack access policies.
Describe alternatives you've considered
The main workaround is to group by the foreign key id and then issue a second query to fetch the related records and manually merge the results. Another option is denormalizing the related field into the base table, but that introduces duplication and consistency issues. Neither approach is ideal compared to first class join support in groupBy and aggregate.
Additional context
This feature would help reduce query count and improve performance for reporting and analytics style use cases. It would also bring groupBy and aggregate closer in parity with common ORM and SQL patterns where joins are available during aggregation.
- 主要言語
- TypeScript
- スター
- 2.9k
- フォーク
- 157
- 平均マージ
- 11時間 42分
- マージ済み PR（30日）
- 20
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
zenstackhq/zenstack のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
zenstackhq/zenstack#2873 ·
メンテナーはふだん 1 日以内に返信
-
runtime
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
zenstackhq/zenstack#2868 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
zenstackhq/zenstack#2694 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
zenstackhq/zenstack#2659 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
zenstackhq/zenstack#2542 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
zenstackhq/zenstack の issue をすべて見る
似ている issue
-
area: backend bug priority: low
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
snapotter-hq/SnapOtter#2254 ·
メンテナーはふだん 1 日以内に返信
-
bug ticket
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
cratestack/cratestack#1154 ·
メンテナーはふだん 1 日以内に返信
-
server 消息处理器 cmd 分支补显式错误回报——竞态非法命令现走未处理拒绝対応中かも @openaddr が今日担当しました。 オープンready-for-agent refactor wayfinder:task
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
openaddr/dafung-web#428 ·
メンテナーはふだん 1 日以内に返信
-
Flaky: mongodb-memory-server 'Port already in use' when another process starts a mongod concurrentlyオープンarea:testing bug effort:S priority:P2
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
lens:agent lens:process process
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
thebristolsound/birdbrain#1772 ·
メンテナーはふだん 1 日以内に返信