Move result-grid query composition into database plugins

[openai0229]

Chat2DB Edition

Chat2DB Community

User Problem

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

This couples the shared result UI to database dialect details, makes the behavior unavailable to other clients and entry points, and will add more frontend branches as database-specific filtering behavior grows.

Concrete Use Case

When a user opens a MongoDB collection and enters FIND or SORT conditions, the result page 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.

Any other client that wants the same result filtering behavior must duplicate the frontend command-composition rules. Changes to projections, cursor chains, sort syntax, pagination, or another database dialect can therefore behave differently across entry points.

Product Area

Database plugin

Proposed Outcome

Result filtering and sorting should have one reusable, database-aware execution contract owned by the backend/plugin layer rather than by the shared frontend UI.

• 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 existing WHERE and ORDER BY behavior.
• The raw query editor continues to accept and execute complete native database commands.
• The behavior covered by fix(mongodb): support native result filtering and sorting #1903 remains the compatibility baseline, including projections, existing cursor chains and sort calls, quoted nested expressions, identifier quoting, and trailing semicolons.
• Backend/plugin tests and frontend contract tests cover the structured request path.

Alternatives Considered

Keep the query composer introduced by #1903 as the permanent implementation. This is a valid narrow bug fix, but it leaves database grammar and parsing inside the frontend and does not provide reusable behavior for other clients.

Another alternative is a generic server-side string rewriter. That would retain brittle string manipulation and should be avoided in favor of an explicit structured contract and database-plugin implementation.

Contribution

I can submit a pull request

Submission Checklist

• I searched existing issues and Discussions for duplicates.
• I selected the affected Chat2DB edition.

Related

• DB查询页面筛选条件兼容问题 #1891
• fix(mongodb): support native result filtering and sorting #1903

[openai0229]

Triage result: Backlog, P2, needs/decision. The direction affects public request contracts, plugin ownership, relational compatibility, and stored query behavior. Before implementation, the Issue needs an accepted structured filter/sort request shape and a migration plan that preserves the #1903 behavior. It is not contributor-ready until that contract is approved and independently testable.

[openai0229]

Architecture design for this proposal is continuing in Ideas Discussion #1944. Keep this Issue open as the Backlog tracking record for the user problem and eventual implementation. Use the Discussion to decide the structured request contract, plugin ownership, compatibility boundary, migration plan, and test matrix. After maintainers approve an independently testable contract, update this Issue with scoped acceptance criteria before moving it to Ready.