Roadmap/Prioritization

[dan-nom]

Hey Matt, it would be great to understand more of your vision for what could be in and out of scope for this extension in the future. I have a pretty long wishlist for my ideal VSCode/BigQuery workflow, but to pick out a few things that would be cool:

• More rendering options for query results (any of: markdown tables, opening a result set in the web ui, a table webview)
• Saving results to CSV or JSON files locally
• Source code snippets
• A sidebar views of datasets, tables and fields
• A language server:
  • Query validation and annotation of errors in line (either through the API, or using a node SQL 2011 validator)
  • Autocompletion of table names
  • Autocompletion of field names

I'm super excited about the possibilities here: BigQuery + VSCode + Git could be really powerful!

[elithrar]

Sure - I'd done some thinking on this behind the scenes, but hadn't written it down yet - so thanks for prompting the conversation!

• One of the things I'd like the most is a language server: getting some basic SQL formatting would be great. Triggering a query run on a file that doesn't have the language mode set would also do that (automatically, unless configured or the file has an existing mode set).
• Building in some snippets would be great - although I'd want to be mindful of bloat here. Maybe a simple SELECT [] FROM `project.dataset.table`, a JavaScript UDF example, etc would be enough.
• Pulling your existing datasets & tables via the API was one I was considering next - being able to browse datasets would be useful, but not sure how critical that is today. Just getting a list of datasets (BigQuery: List Datasets in Project) would be a good first start. You can list the tables via SELECT * FROMproject.dataset.TABLES` until then (a snippet!)
• A sidebar view of datasets & tables would definitely be the next step - similar to how the GitHub Pull Requests extension works. Show datasets (rolled up, at first) and then allow a user to expand. Might have to see how we support 50+ tables per dataset though - you can have far more, but the sidebar may not scale well beyond 10-20 from a UX perspective.
• Exporting results locally = yes.
• More rendering options = definitely being to open a job in the Web UI - "BigQuery: Open Last Job in Browser" and taking a user to https://console.cloud.google.com/bigquery?project=${projectId}&j=${jobId}&page=queryresults would do the trick. I'm OK with Markdown, but the table rendering code (since BQ has nested fields) is already fragile, which isn't great, so perhaps even just replace the current table formatting with a Markdown driven engine if there's something more robust here.

In order of "priority" and taking into account ease-of-implementation) I see it as: exporting results locally > SQL formatting > sidebar > open in browser > additional rendering options.

Happy to divvy up the work here too. I can't commit mountains of time to this, and I have a number of other OSS projects that keep me treading water as-is, but I can at the very least commit to timely reviews & feedback.

[dan-nom]

Thanks for the reply! I also cannot commit a huge amount of time, but happy to add in features where I can.

Perhaps a next step is to file some issues for more incremental improvements which I (or other contributors 🤞) can work on when we have the time.

For the bigger chunks of work, like a language server, where some consideration is needed for architecture we could either create issues for discussion or docs for planning?

Happy to follow your lead on best way to proceed.

[elithrar]

Yep - I think adding some issues for these will be useful to help scope.

RE: the language server - I think leaving that until there's more obvious adoption is acceptable. We can however certainly implement format-on-save functionality for any mode: SQL file - as a config option that can also format the query in the editor buffer prior to sending it to the BQ API (formatting afterwards will cause a query-cache miss).

We can use https://github.com/zeroturnaround/sql-formatter - which is well documented, tested and more than fast enough.

Example: https://runkit.com/elithrar/sql-format-bigquery-example

On Fri, Oct 19, 2018 at 9:49 AM Dan Massey notifications@github.com wrote:

Thanks for the reply! I also cannot commit a huge amount of time, but happy to add in features where I can.

Perhaps a next step is to file some issues for more incremental improvements which I (or other contributors 🤞) can work on when we have the time.

For the bigger chunks of work, like a language server, where some consideration is needed for architecture we could either create issues for discussion or docs for planning?

Happy to follow your lead on best way to proceed.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/google/vscode-bigquery/issues/3#issuecomment-431426835, or mute the thread https://github.com/notifications/unsubscribe-auth/AABIcKRGxPKrhFG4OpJIhg2VVTBQkcKkks5umgKLgaJpZM4XvrKC .

--