-
Notifications
You must be signed in to change notification settings - Fork 409
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
Aggregation operators refactor #2664
Aggregation operators refactor #2664
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #2664 +/- ##
==========================================
- Coverage 62.71% 62.67% -0.04%
==========================================
Files 432 435 +3
Lines 22256 22378 +122
==========================================
+ Hits 13958 14026 +68
- Misses 7370 7425 +55
+ Partials 928 927 -1
Flags with carried forward coverage won't be shown. Click here to find out more. |
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.
Great work!
internal/handlers/common/aggregations/operators/accumulators/accumulators.go
Show resolved
Hide resolved
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.
As discussed, almost everything is ready.
Things to clarify are:
- we shouldn't use
go gen
where it's not needed and we should delete previously generated files - iterators are still better than slices, so we don't need to keep everything in memory
switch - case
with similar errors
internal/handlers/common/aggregations/operators/operators_error.go
Outdated
Show resolved
Hide resolved
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.
Overall looks good! Let's move the errors to a separate function as discussed on the call!
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.
Overall looks good! Let's move the errors to a separate function as discussed on the call!
|
||
// Error implements the error interface. | ||
func (e *OperatorError) Error() string { | ||
return fmt.Sprint(e.code) |
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 using stringer and error names instead of error code will make things much simpler
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.
To simplify it as much as possible can't we just do:
var (
// ErrWrongType indicates that operator field is not a document.
ErrWrongType = fmt.Errorf("Invalid type of operator field (expected document)")
// ErrEmptyField indicates that operator field does not specify any operator.
ErrEmptyField = fmt.Errorf("The operator field is empty (expected document)")
// ErrTooManyFields indicates that operator field specifes more than one operators.
ErrTooManyFields = fmt.Errorf("The operator field specifies more than one operator")
// ErrNotImplemented indicates that given operator is not implemented yet.
ErrNotImplemented = fmt.Errorf("The operator is not implemented yet")
)
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.
Yes, but then exhaustive linter will not be able to help you
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 didn't complain
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.
Exactly. It will never complain, even if you remove some case
s
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 see, should I replace it with stringer? Also, we use similar logic in pgdb
, regex
, hanadb
, and commonparams
should it be replaced either?
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 depends on whatever the switch on those values should be exhaustive
@noisersup this pull request has merge conflicts. |
Co-authored-by: Dmitry <dmitry.eremenko@ferretdb.io>
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.
👍
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 looks to me that the questions we discussed are fixed! Great beginning to have a better structure for accumulators and operators!
Description
Closes #2317.
Readiness checklist
task all
, and it passed.@FerretDB/core
), Labels, Project and project's Sprint fields.