Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1-to-1 execution model is too rigid #45

Open
chipkent opened this issue Jul 16, 2024 · 2 comments
Open

1-to-1 execution model is too rigid #45

chipkent opened this issue Jul 16, 2024 · 2 comments
Labels
enhancement New feature or request
Milestone

Comments

@chipkent
Copy link
Member

Plugin: 1.3.0 pre

The current version of the plugin is modeled off of the Deephaven IDE. As such, VS Code has one connection to one DH instance. This is basically like having an IDE and saying that it can only ever have one process running at a time. This is fine for simple cases, but multi-process / multi-query is where things often end up.

Consider JetBrains. When a job is run, it can be configured to run a specific script in a specific container or environment. This is much more flexible.

Imagine a case where a developer has two queries.

  • Query 1: Has access to restricted data. Does some massaging of the data to produce less restricted output data.
  • Query 2: Uses the less restricted output data to do stuff.

With the 1-to-1 model, we have to tell them to do all of query 1 and then reconnect and do all of query 2. Maybe this is fine. Maybe it becomes annoying in reality.

There are other limitations such as no way to display plots from two queries at once.

With the DH IDE, it is possible to spin up multiple servers on different ports and connect a different browser tab to each. Is there a similarly clean way to spawn multiple VS Code sessions pointed at different DH instances without it feeling clunky?

No matter what, there are tradeoffs with respect to 1-vscode-to-1-deephaven vs 1-vscode-to-N-deephaven. Have the relative tradeoffs been considered?

@chipkent chipkent added enhancement New feature or request triage labels Jul 16, 2024
@vbabich
Copy link

vbabich commented Jul 24, 2024

We need to consider the UX on this. Ties in with #7

@vbabich vbabich added this to the August 2024 milestone Jul 24, 2024
@vbabich vbabich removed the triage label Jul 24, 2024
@bmingles
Copy link
Collaborator

@chipkent I think this will be addressed as part of DHC: Worker lifecycle management #7

@mofojed mofojed modified the milestones: August 2024, November 2024 Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants