Add Feature Download as JSON for specified connection MongoDB

[sapisuper]

Changes :

• Add capability to Download as JSON in Request Query specified MongoDB connection only
• Download as JSON also support in Live access but only for MongoDB connection

---

Important

Add JSON download feature for MongoDB queries, including backend handling and frontend UI updates.

• Backend:
  • Add downloadJson() in ExecutionRequestController.kt to handle JSON downloads for MongoDB connections.
  • Implement streamResultsAsJson() in ExecutionRequestService.kt to stream MongoDB query results as JSON.
  • Add executeAndStreamAll() in MongoDBExecutor.kt to execute and stream MongoDB queries.
  • Add jsonDownloadAllowed() in ExecutionRequest.kt to check JSON download permissions.
• Frontend:
  • Add JSONDownloadSchema in ExecutionRequestApi.ts to handle JSON download permissions.
  • Update LiveSession.tsx to include a "Download as JSON" button for MongoDB connections.
  • Update DatasourceRequestBox.tsx to include a menu item for JSON download for MongoDB connections.

^{This description was created by for 53f0c1e. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 53f0c1e in 1 minute and 51 seconds. Click for details.

• Reviewed 315 lines of code in 7 files
• Skipped 0 files when reviewing.
• Skipped posting 6 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. backend/src/main/kotlin/dev/kviklet/kviklet/service/ExecutionRequestService.kt:595

• Draft comment:
  In streamResultsAsJson, a generic RuntimeException is thrown when JSON download isn’t allowed. Consider using a more specific exception type to improve error handling and clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The suggestion has merit since IllegalStateException is more specific and semantically appropriate for invalid state conditions. However, the code consistently uses RuntimeException for all validation in this method (lines 604, 607). Changing just one would create inconsistency. The change would be better if it was part of a broader refactoring of all exception handling. The comment identifies a valid improvement but ignores the broader context of exception handling patterns in the code. A piecemeal change could reduce code consistency. While the suggestion would be an improvement in isolation, maintaining consistency in error handling patterns within a method is also important for code maintainability. The comment should be deleted as it suggests a localized change that would create inconsistency with the surrounding code's error handling patterns.

2. backend/src/main/kotlin/dev/kviklet/kviklet/service/MongoDBExecutor.kt:96

• Draft comment:
  Ensure that only 'find' queries are processed for JSON export. Consider further validating the query structure if necessary.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

3. backend/src/main/kotlin/dev/kviklet/kviklet/service/dto/ExecutionRequest.kt:327

• Draft comment:
  The jsonDownloadAllowed validation for MongoDB requests bypasses JSQLParser. Ensure that accepting the raw JSON query without extra validation is safe.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The code shows that MongoDB queries only get basic validation (non-empty, trimmed, semicolon removed). However, MongoDB uses a completely different query language than SQL, so JSQLParser wouldn't be appropriate here. The code already has other safeguards like requiring approval and checking execution status. The comment is speculative about security without concrete evidence of an issue. I could be underestimating the security implications of not having strict MongoDB query validation. There might be MongoDB-specific injection or security concerns I'm not considering. While query validation is important, suggesting there might be a security issue without specific evidence violates our rule about speculative comments. The appropriate validation for MongoDB queries would be different from SQL validation anyway. The comment should be deleted as it is speculative and asks for verification without demonstrating a concrete issue. If there are specific MongoDB query validation concerns, they should be raised with concrete examples.

4. frontend/src/routes/LiveSession.tsx:88

• Draft comment:
  The editor command (Shift+Enter) is added outside of a useEffect. This may result in duplicate registrations on re-renders. Move this registration into a useEffect hook that depends on the editor instance.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

5. frontend/src/routes/LiveSession.tsx:156

• Draft comment:
  The JSON download button is conditionally rendered for MongoDB connections. Ensure the user receives proper feedback if download isn’t allowed, similar to CSV download.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is speculative - it assumes there needs to be error feedback but doesn't point to any specific issue. Both download implementations are similar, suggesting they likely have the same error handling at the API level. The comment isn't pointing out a clear bug or issue, just suggesting a hypothetical improvement without evidence of a problem. The download functionality might fail in ways that aren't obvious from the code, and proper error handling is generally good practice. Maybe there are MongoDB-specific failure modes that need special handling. Without evidence of actual download failures or specific error cases that need handling, this is a speculative suggestion. The JSON download implementation mirrors the existing CSV download approach which appears to be working. The comment should be deleted as it's speculative and doesn't point to a concrete issue requiring changes. It asks for verification without clear evidence of a problem.

6. frontend/src/routes/Review/DatasourceRequestBox.tsx:81

• Draft comment:
  The JSON download menu item is added for MongoDB requests. Review that using a direct link without an onClick handler is acceptable for your UX.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is asking for a UX review of using direct links, but this appears to be an established pattern in the codebase since CSV downloads work the same way. The comment is more of a UX discussion point rather than a clear code issue. It's asking for confirmation rather than pointing out a definite problem. The code could potentially benefit from consistent handling of downloads, and maybe there's a good reason to have an onClick handler that I'm missing. However, this is an established pattern in the codebase, and the comment is asking for confirmation rather than identifying a clear issue that needs fixing. The comment should be deleted as it's asking for confirmation of an intentional pattern rather than identifying a clear code issue that needs fixing.

Workflow ID: wflow_VbStREywE9iMP4DY

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}