-
Notifications
You must be signed in to change notification settings - Fork 2.2k
refactor: avoid import drivers from types #1759
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1759 +/- ##
==========================================
+ Coverage 85.32% 85.69% +0.37%
==========================================
Files 135 135
Lines 6903 6921 +18
==========================================
+ Hits 5890 5931 +41
+ Misses 1013 990 -23
Continue to review full report at Codecov.
|
Latency summaryCurrent PR yields:
Breakdown
Backed by latency-tracking. Further commits will update this comment. |
e1773ef
to
bf6e589
Compare
bf6e589
to
e90a770
Compare
e90a770
to
11831b1
Compare
11831b1
to
a803036
Compare
ca3b14b
to
bd0c3e2
Compare
bd0c3e2
to
710e04b
Compare
I think we can invert the logic and have a QueryLang created from a Driver instead of passing a Driver to QueryLang. |
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 agree upon that the types should not import drivers because conceptually drivers are one level higher than the types. However, I'm not sure using tuples for initializing QueryLang
is a good solution. For me, it doesn't feel pythonic.
Co-authored-by: Nan Wang <nan.wang@jina.ai>
Co-authored-by: Nan Wang <nan.wang@jina.ai>
I agree it does not feel the best way, I think what we could do is to have a Maybe the best solution would be to put |
Hey @nan-wang can you see if you like the new changes? |
No description provided.