Code lens for .sql files and/or inlined sql fences

[archiewood]

Aware that this is a "next week" (rather than right now) task but wanted somewhere to write about this.

Feel free to break down into smaller issues and close this one if it makes sense.

Draft Acceptance Criteria (to be refined)

• User can run SQL file queries in VSCode and get results into some kind of visual output
• Works for any supported database adapter
• Works for chained queries
• (Optional) User can run inline queries in VSCode. Results are returned in table ?below the markdown fence in the code
• (Optional) User gets autocomplete for their database. @RandomFractals I think you suggested we might be able to rely on another extension for this. If this is hard / time consuming then deprioritize.
• (Very optional) User can see tables, schemas etc in their database in some kind of sidebar. I have no idea how hard this is, and may want to deal with separately, possibly in the future.

Other thoughts

• We should try to sensibly handle if a user tries to select * from table and return 100,000 rows to VSCode. Should we break, return error, paginate

[RandomFractals]

We'll take your notes and design ideas for this feature into consideration.

However, this is not the limited initial set of SQL Query Code Lens feature that is in scope and to be delivered next week.

Let's draft the Acceptance Criteria after we actually define the target feature details, SQL Query Code Lens and our initial tabular data results display approach in this case.

[archiewood]

Gotcha, have we got that "in scope next week" written down anywhere yet?

[RandomFractals]

yes, we have the scope defined in our 3 week project SOW, notes, confirmation and review of that scope from this morning in the related slack channel for this project I can't link to because it's private.

This feature will be defined and reviewed during our Sprint 3 planning meeting we'll kick off next week.

What you have above is a very generic wish list, with some desirable options/UI features that lack the detail, or related tools info and integration options and descriptions that will be outlined for Sprint 3 in a separate feature ticket.

For those reasons, I will close this ticket for now, so that we don't set inappropriate and vague expectations of what will be included in the initial set of this feature.

Thank you for providing links to the related Evidence documents. I've seen them already, and will actually need to review the related Evidence data apis and code instead to identify the best dev/integration route for this feature implementation.