-
Notifications
You must be signed in to change notification settings - Fork 44
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
Implement new await synchronous interface #498
Implement new await synchronous interface #498
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #498 +/- ##
==========================================
+ Coverage 99.81% 99.85% +0.03%
==========================================
Files 9 10 +1
Lines 542 671 +129
==========================================
+ Hits 541 670 +129
Misses 1 1 ☔ View full report in Codecov by Sentry. |
ff3856a
to
5fbcab1
Compare
@brunoocasali this is pretty much complete, please feel free to review when you have (a lot of) time. 👨💻 🤯 |
b82e2d1
to
f4d63c8
Compare
Rebased and force pushed. |
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.
Thanks a lot for your hard work here @ellnix amazing!
I am asking for some changes but it is nothing to be worried about!
# frozen_string_literal: true | ||
|
||
describe MeiliSearch::Model::Task do | ||
let(:new_index_uid) { random_uid } |
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.
Can you apply the xUnit
structure here? And the https://betterspecs.org guides about the naming of the contexts using with/when
?!a
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.
The contexts have been renamed.
About the xUnit
structure, I am assuming you specifically mean the setup, exercise, verify, and teardown steps?
- setup is done in rspec
let
s which by design are shared so do not directly appear in a test's body, should I clarify them somehow or have a line in each test explicitly create the correct context for clarity? - exercise and verify are often in the same line of code for brevity, should I expand them?
- teardown is also handled by rspec
let
s, and as far as I know there is no context leaking between specs
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.
Amazing work @ellnix I think we could make some small modifications, but I was impressed, very good work!
5e375ff
to
5ea3aab
Compare
@brunoocasali sorry for taking so long to get back to this. I addressed your feedback and rebased it to main (for the changes since you last reviewed it, start at commit b141ed4). P. S.: The tests pass but codecov is broken again. |
let's see if the code coverage will still be broken now! Also, can you squash the commits @ellnix ? |
Squash them into a single commit or just fewer commits? How many commits would you consider ideal? The history might be a little bit hard to follow if only a few commits had +1800 -1200 changes. |
# frozen_string_literal: true | ||
|
||
describe MeiliSearch::Model::Task do | ||
let(:new_index_uid) { random_uid } |
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.
The contexts have been renamed.
About the xUnit
structure, I am assuming you specifically mean the setup, exercise, verify, and teardown steps?
- setup is done in rspec
let
s which by design are shared so do not directly appear in a test's body, should I clarify them somehow or have a line in each test explicitly create the correct context for clarity? - exercise and verify are often in the same line of code for brevity, should I expand them?
- teardown is also handled by rspec
let
s, and as far as I know there is no context leaking between specs
A few commits would be great. I don't have a number for that, it is more a feeling than anything. If you squash them based on the group like, you did a lot of the same but in multiple files, so in my mind you would have a single commit of that "theme". |
1db64a5
to
5151609
Compare
@brunoocasali should be ready for merge, unless you want me to squash it down further. |
allow(subject).to receive(:refresh) | ||
subject.enqueued? | ||
expect(subject).not_to have_received(:refresh) |
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.
When I mention the xUnit I mean this:
allow(subject).to receive(:refresh) | |
subject.enqueued? | |
expect(subject).not_to have_received(:refresh) | |
allow(subject).to receive(:refresh) | |
subject.enqueued? | |
expect(subject).not_to have_received(:refresh) |
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'm not sure this will work, but addressing the conflict with a commit might dismiss the approval review. bors merge |
Merge conflict. |
Give me a second with this, apparently the git pull on my fork didn't go through properly and now everything is messed up. |
Refactor all doc methods & specs with Model::Task Update global settings methods to use Model::Task Update ranking_rules methods to use Model::Task Update distinct attribute methods with Model::Task Update searchable attr methods to use Model::Task Update displayed attrs methods with Model::Task Update synonoms methods to use Model::Task Update stop words methods to use Model::Task Update filterable attrs methods to use Model::Task Update sortable attrs methods to use Model::Task
Update typo tolerance methods with Model::Task Update faceting settings methods with Model::Task Update user dict methods to use Model::Task Update (non) separator methods to use Model::Task Update Index#update and #delete to use Model::Task
Replace calls to wait_for_task in specs which I had missed somehow Remove now-redundant TaskHelpers Update some Client methods&specs with Model::Task Add Model::Task to Client#dump and other specs
6059ff7
to
75017dc
Compare
Well I fixed the git history and force pushed. Sorry about the issues but I don't think there was a way for me to resolve the main conflicts without automatically dismissing the approval review (even when I tried a merge rather than a rebase). I looked it up, it seems to be a setting (isaacs/github#783 (comment)) but it does not look like it would be a good idea, since it would allow someone with approval to push arbitrary code and then choose to merge. |
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.
LGTM!
bors merge |
Build succeeded:
|
Pull Request
Related issue
Fixes #288
While refactoring, inadvertently fixes:
PR checklist
Please check if your PR fulfills the following requirements:
Changes Checklist