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

Support for Global Variables / Notebook Parameters #28

Open
okennedy opened this issue Jul 5, 2019 · 2 comments
Open

Support for Global Variables / Notebook Parameters #28

okennedy opened this issue Jul 5, 2019 · 2 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@okennedy
Copy link
Collaborator

okennedy commented Jul 5, 2019

TL;DR: Allow notebooks to declare single-valued parameters instead of needing to create single-cell datasets.

A frequent request at SIGMOD was for notebook parameters. The idea is to abstract out specific workflow configuration elements into a separate area of the notebook. These parameters would then be accessible in individual cells. For example:

  • Python and Scala cells could use the vizierdb object (e.g., vizierdb['myparameter']) or similar.
  • SQL cells could use JDBC parameters (e.g., SELECT * FROM foo WHERE bar = ?myparameter) or similar
  • PLOT cells culd use something like SQL cells (i.e., ?myparameter) or possibly a pop-up menu for column selections
  • LOAD DATA cells could take a URL or uploaded file as a parameter.

The primary benefit of parameters is that it becomes possible to export the notebook functionality as a library. To allow external notebooks to call in to this notebook, you need to have a way to communicate configuration options from outside -- parameters are a natural way to do this.

There are a few secondary benefits

  • It makes it easier to isolate and track the provenance of specific configuration parameters.
  • It makes it easier to pass common state between cells (e.g., instead of creating single-cell datasets).
  • It puts configuration parameters and other magic values front and center, making it easier to change major features of the workflow in one place. (as an aside, these parameters would be overridden when the notebook is exported as a library --- this is great for development!)
  • It could, in principle, enable better integration with interactive visualization tools like Bokeh. Bokeh has a server mode that allows the frontend to pass back parameters to the code generating the visualization. We could track the provenance of such parameters, and allow those parameters to be re-used in subsequent cells.

Parameters could be typed: including native types (int, float, string, date, etc...), as well as workflow-specific types (column-set, dataset, etc...). That in turn lets us create custom UIs for each type (e.g., file uploading for datasets).

@okennedy okennedy added enhancement New feature or request question Further information is requested labels Jul 5, 2019
@julianafreire
Copy link

@okennedy
Copy link
Collaborator Author

okennedy commented Jul 5, 2019

Yes, exactly this... though with a first-class treatment in the UI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants