[Idea] Move result-grid query composition into database plugins

[openai0229]

Relevant edition

Chat2DB Community

Problem or workflow

The result-grid filter and sort controls currently construct database-specific executable query strings in the frontend. PR #1903 corrected MongoDB behavior by composing db.<collection>.find(...).sort(...) in TypeScript, but this leaves the shared UI responsible for MongoDB command grammar.

That ownership makes the behavior unavailable to other clients and execution entry points, and it will add more frontend branches as database-specific filtering behavior grows.

Who is affected?

Users who browse MongoDB collections through the result grid are affected directly. Maintainers of the shared result UI, backend execution contract, and database plugins are affected whenever filtering, sorting, projections, cursor chains, pagination, or dialect behavior changes.

Any additional client that needs the same behavior must currently duplicate the frontend command-composition rules, which can cause inconsistent behavior across entry points.

Current workaround

The Community frontend receives an original command such as db.users.find(), rewrites it into a complete MongoDB command, and posts that string to /api/rdb/dml/execute. The MongoDB backend executor then sends the command to the JDBC driver.

This is a valid compatibility fix for the immediate bug, but it keeps database grammar and parsing in the frontend. A generic server-side string rewriter would move the same brittle approach without establishing a reusable contract.

Desired outcome

Result filtering and sorting should use one reusable, database-aware execution contract owned by the backend and plugin layer.

• The result UI submits structured filter and sort intent instead of constructing a complete database command.
• The MongoDB plugin owns MongoDB find(...) and .sort(...) composition.
• Relational databases preserve their current WHERE and ORDER BY behavior.
• The raw query editor continues to accept and execute complete native database commands.
• The behavior delivered by fix(mongodb): support native result filtering and sorting #1903 remains the compatibility baseline.
• Backend/plugin tests and frontend contract tests cover the structured request path.

Decisions required before implementation

• Define the structured filter/sort request shape and its versioning boundary.
• Decide whether the contract belongs to the existing DML endpoint or a dedicated result-query endpoint.
• Define plugin responsibilities for validation, identifier quoting, composition, and error reporting.
• Preserve projections, existing cursor chains and sort calls, quoted nested expressions, identifier quoting, trailing semicolons, and relational behavior.
• Define migration and compatibility behavior for existing clients and stored queries.
• Produce an independently testable backend/plugin and frontend contract matrix.

This is an exploratory architecture proposal, not an accepted roadmap item or contributor-ready task. After maintainers approve the contract, the open tracking Issue #1911 should be updated with explicit, independently testable acceptance criteria before it moves to Ready.

Examples or references

• Original tracking Issue: Move result-grid query composition into database plugins #1911
• Related Feature Issue: DB查询页面筛选条件兼容问题 #1891
• MongoDB compatibility implementation: fix(mongodb): support native result filtering and sorting #1903

Contribution interest

I can help implement or test this after the architecture contract is approved.