-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add async supoort for SEARCH commands #2096
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2096 +/- ##
==========================================
+ Coverage 92.45% 92.59% +0.14%
==========================================
Files 104 105 +1
Lines 24364 25085 +721
==========================================
+ Hits 22526 23228 +702
- Misses 1838 1857 +19
Continue to review full report at Codecov.
|
@@ -857,3 +857,245 @@ def syndump(self): | |||
""" # noqa | |||
raw = self.execute_command(SYNDUMP_CMD, self.index_name) | |||
return {raw[i]: raw[i + 1] for i in range(0, len(raw), 2)} | |||
|
|||
|
|||
class AsyncSearchCommands(SearchCommands): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could see this becoming too difficult to maintain. WDYT about moving this into async_commands.py?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might get messy once you start thinking about the other Redis modules like AI and their own async counterparts.
It might help to choose either of these options instead:
- Under the current commands folder, create an asyncio module
- Under the asyncio module, create a new commands directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's true - commands are becoming unwieldy. Is there a more accepted pattern for maintaining async support? What about the following pattern (note my being new to async), yes this might break things:
- Create functions for each command (i.e set) prefixed with double underscores to denote private
- Create their implementations in both async and sync versions, with execute_command being different, to support async/await.
Gut check: Does this seem painful as you'd now need to create one implementation and two wrappers per function? Alternatively we could generate #2 quite frankly, easily enough.
@Andrew-Chen-Wang thoughts? I'm just spitballing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the only patterns that I've seen adopted are to use an a- or async- prefix (eg Python itself, django) or to have separated mixins (eg Elasticsearch-py).
And mm the current implementation of an abstraction of execute_command, to me, is the most viable method of maintainence. I think adding too many ways of separation between sync and async will make redis-py more bloated and unmaintainable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I think that's out of scope for this (obviously!) but let's not lose track. I'm literally going to open a GH issue, and link to this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dvora-h see the duplication of testsdata. Beyond that, it's clean given our current implementation.
Pull Request check-list
Please make sure to review and check all of these items:
$ tox
pass with this change (including linting)?NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.
Description of change
Please provide a description of the change here.