weaviate-python-client
weaviate-python-client copied to clipboard
Refactor to separate sync and async connections
This PR constitutes a complete overhaul of the codebase structure with respect to the underlying connections of the WeaviateClient and WeaviateAsyncClient classes and how they are provided to them. Currently, the WeaviateClient works by using the same ConnectionV4 (which is async) object under-the-hood that the WeaviateAsyncClient uses only with the calls scheduled in a side-car event loop thread.
With this PR, this is has been refactored so that the connection can be dependency injected into the business logic layer of the client from the top-down so that all namespaces in WeaviateClient now explicitly depend on ConnectionSync, which itself depends on httpx.Client and grpc.Channel, with ConnectionV4 renamed to ConnectionAsync that still depends on httpx.AsyncClient and grpc.aio.Channel.
This is achieved using the command pattern whereby all business logic of the client is encapsulated into Executor classes, e.g. _DataExecutor, which expose methods that exactly match those of the public API plus an additional argument: connection: ConnectionSync | ConnectionAsync. Then, at runtime, the connection is injected into the executor call by the decorator @weaviate.connect.impl.generate("sync" | "async") so that we can have a single implementation of the inner business logic in the executor that is agnostic to exactly which connection is passed to it. The executor methods work with the union of connections by utilising the logic in weaviate/connect/executor.py, which is effectively an ad hoc implementation of callbacks.
This PR introduces the fundamental structure of the overall pattern that the client should use moving forward. However, there is a large amount of boilerplate associated with the stitching together of the sync/async clients with the executors. This should be automated in the future through custom-built auto-generation tools that translate the API surfaces of the executors into the async_.pyi and sync.pyi stub files of each namespace. Until then effort should also be spent developing a custom flake8 linter to validate that the namespace async_.pyi and sync.pyi files are identical.
Great to see you again! Thanks for the contribution.
beep boop - the Weaviate bot 👋🤖
PS:
Are you already a member of the Weaviate Slack channel?
Codecov Report
Attention: Patch coverage is 86.08113% with 374 lines in your changes missing coverage. Please review.
Project coverage is 87.82%. Comparing base (
9ef4682) to head (4ce71b8). Report is 123 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #1594 +/- ##
==========================================
- Coverage 88.39% 87.82% -0.57%
==========================================
Files 187 219 +32
Lines 16015 17492 +1477
==========================================
+ Hits 14156 15362 +1206
- Misses 1859 2130 +271
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
This change broke unit tests for me, because suddenly the create and other method on this AsyncMock(spec=_CollectionsAsync) are created as MagicMock, rather then AsyncMock...
Hi @eavanvalkenburg, thanks for raising! I'll look into how we can work around that and release a fix
was able to work around it, by doing this:
# previous code:
async_mock = AsyncMock(spec=WeaviateAsyncClient)
async_mock.collections = AsyncMock(spec=_CollectionsAsync)
# new additions:
async_mock.collections.create = AsyncMock()
async_mock.collections.delete = AsyncMock()
async_mock.collections.exists = AsyncMock()