Support `obstore` connection pooling
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 80
- Forks
- 8
- Avg merge
- 21h 44m
- Merged PRs (30d)
- 5
Description
To be clear here, what this is doing is taking the configuration from an existing obstore store and recreating a new store with the same parameters in the currently-linked
object_storecrate. So that means any connection pooling will not be shared between the user's inputobstoreinstance and the instance you use to make your own fetches.That's why the original idea in
pyo3-object_storewas that downstream crates would re-export the obstore store creation API, so that there wouldn't be any of this "dynamic linking" across crates. Since we don't have real dynamic linking, in effect we have to re-create all the necessary resources in the target pyo3 module.
Originally posted by @kylebarron in https://github.com/zarrs/zarrs-python/pull/138#discussion_r2676529080
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.
Research direction
Start with the discussion in pull request #138 and trace how the existing obstore configuration is recreated against the linked object_store crate. Determine the supported connection-pooling path and verify that pooling is shared rather than recreated for fetches.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, rust
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100