What objects can/should be shared/reused?
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Documentation
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- azure, node.js, sql, typescript
- Domain
- backend, cloud, documentation
Research direction
Start with the existing client/session/operation lifecycle guidance and the hello-world sequence described in the issue, then compare them with the Azure Functions HTTP-trigger scenario. Document when each object is finished, what can be reused, and the cleanup and reinitialization behavior requested; verify that the guidance answers the singleton questions.
Written by the indexing model from the issue text.
Description
Reading through and the documentation doesn't seem to be clear on how to handle long running processes that fetch data at intervals over time.
The "hello world" paradigm that we see here:
- Get a client
- Get a session from the client
- Perform an operation on the session
- Close the operation
- Close the session
- Close the client
If we have something like an http trigger in an Azure functions instance, what can be reused:
- Can we share a client as a singleton, or do we need a new one for each http request that comes in and executes a query?
- Can we share a session as a singleton, or do we need a new one for each http request that comes in and executes a query?
If resources can be used as singletons, what's the recommended error handling to make sure that they get cleaned up & reinitialized if there's an error?
The only guidance is just
"After you finish working with the operation, session or client, it is better to close it, each of them has a respective method (close())."
The basic question here: at what point do we consider ourselves "finished" working with each object?
- Dominant language
- TypeScript
- Stars
- 36
- Forks
- 50
- Avg merge
- 13h 46m
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from databricks/databricks-sql-nodejs
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
engineer-bot
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
databricks/databricks-sql-nodejs#274 · 1 comment · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
All issues in databricks/databricks-sql-nodejs
Similar issues
-
clawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:message-loss issue-rating: 🦞 diamond lobster maturity:stable P2
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
ZCode 3.14.3 に対応する Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
supermomonga/zcode-acp#24 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
growthbook/growthbook#7100 ·
-
triage
Difficulty 1/5 1-3 hours Newbie friendliness 88/100