Don't write .lock file when loading from an existing collection
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.4k
- Forks
- 301
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 37
Description
I have stored a qdrant collection locally on my computer to access it for testing purposes. I am building a chatbot app in gradio and it requires to load the app.py many times to develop it in iterations.
However, every time I load the collection a .lock file is automatically created which I have to manually delete each time when loading app again for my application. Otherwise I run into following error:
RuntimeError: Storage folder qdrant/ is already accessed by another instance of Qdrant client. If you require concurrent access, use Qdrant server instead.
The code to load the collection is as follows:
vectors = QdrantVectorStore.from_existing_collection(
path="qdrant/",
collection_name="uganda-documents",
embedding = HuggingFaceEmbeddings(
model_kwargs = {'device': device},
encode_kwargs = {'normalize_embeddings': bool(int(config.get('retriever','NORMALIZE')))},
model_name=config.get('retriever','MODEL')
)
)
I would like to either automatically delete the .lock file or to not create it at all in the first place. Is this possible within Qdrant or do I have to build a manual work around?
I know I could simply add something like a os.remove("qdrant/.lock") but it seems not very intuitive.
Contributor guide
No contributing guide indexed for this repository
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 at the QdrantVectorStore.from_existing_collection entry point used in app.py and trace how the local qdrant/ storage client is opened and released. Check the existing local-storage tests, if available, for lock-file behavior. Done means repeatedly loading the existing collection does not leave a lock that blocks the next load.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100