Add the concept of DB selectors#58
Merged
smukil merged 3 commits intocloudspannerecosystem:mainfrom Sep 18, 2025
Merged
Conversation
added 2 commits
September 17, 2025 20:32
This change is added to minimize code-duplication between internal and
OSS codebases.
The primary difference between internal and cloud is the params used to
connect to them. We can create the concept of DB selectors which
encapsulate details of the underlying DB being connected to.
Hence, instead of passing cloud specific parameters
(`--database/--instance/--project`), these selectors can be plumbed
through the code.
- 3 types of selectors are implemented: CLOUD, INFRA, MOCK
- Passing the following options to %%spanner_graphs selects the
appropriate DB:
- `--mock` selects a Mock Spanner database.
- `--project <> --instance <> --database` selects a Cloud Spanner
database.
- `--infra_db_path <>` selects an Infra database
- Core cloud and infra related database code already separated.
cloud_database.py will be available in OSS and the infra version will
not. So `infra_db_path` will not work in OSS and vice versa. MOCK will
be supported in both internal and OSS.
- A new JSON based wire format between JS and Python is added:
{
"selector":
{"env": "SpannerEnv.MOCK/CLOUD/INFRA",
"project": "<>",
"instance": "<>",
"database": "<>",
"infra_db_path": "<>"},
"graph": "<>"
}
For example the protocol for cloud could look like:
{
"selector":
{"env": "SpannerEnv.CLOUD",
"project": "span-cloud-testing",
"instance": "graph-demo",
"database": "viz-demo",
"infra_db_path": null},
"graph": "FinGraph"
}
Similarly INFRA would have infra_db_path populated and the rest as null.
- Also fixes the frontend/static/test
cf0e140 to
958fb37
Compare
cqian23
approved these changes
Sep 18, 2025
Collaborator
cqian23
left a comment
There was a problem hiding this comment.
tested and worked well so far
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change is added to minimize code-duplication between internal and OSS codebases.
The primary difference between internal and cloud is the params used to connect to them. We can create the concept of DB selectors which encapsulate details of the underlying DB being connected to. Hence, instead of passing cloud specific parameters (
--database/--instance/--project), these selectors can be plumbed through the code.3 types of selectors are implemented: CLOUD, INFRA, MOCK
Passing the following options to %%spanner_graphs selects the appropriate DB:
--mockselects a Mock Spanner database.--project <> --instance <> --databaseselects a Cloud Spanner database.--infra_db_path <>selects an Infra databaseCore cloud and infra related database code already separated. cloud_database.py will be available in OSS and the infra version will not. So
infra_db_pathwill not work in OSS and vice versa. MOCK will be supported in both internal and OSS.A new JSON based wire format between JS and Python is added: {
"selector":
{"env": "SpannerEnv.MOCK/CLOUD/INFRA", "project": "<>", "instance": "<>", "database": "<>", "infra_db_path": "<>"}, "graph": "<>" }
For example the protocol for cloud could look like: {
"selector":
{"env": "SpannerEnv.CLOUD",
"project": "span-cloud-testing",
"instance": "graph-demo",
"database": "viz-demo",
"infra_db_path": null},
"graph": "FinGraph"
}
Similarly INFRA would have infra_db_path populated and the rest as null.