-
Notifications
You must be signed in to change notification settings - Fork 23
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
Numeric range support #403
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #403 +/- ##
==========================================
- Coverage 96.63% 95.98% -0.65%
==========================================
Files 24 25 +1
Lines 3179 3414 +235
==========================================
+ Hits 3072 3277 +205
- Misses 72 93 +21
- Partials 35 44 +9 ☔ View full report in Codecov by Sentry. |
Wow, this is huge. Thank you! Before I get into a serious review, a few remarks:
Once again, thank you @sathishdv for this work! |
Hi @timbray I will be providing the details soon. Will keep you posted |
@sathishdv - OK, I read the code and figured out what you are doing, in However, this is a large departure from the design of Quamina. The basic idea of Quamina is that all the patterns for a field value are compiled together into an NFA and then traversing the NFA for any field tells which patterns matched. This has the result that the behavior is nearly O(1) in the number of rules. This implementation it would be O(N). (Or maybe I'm missing something? Please tell me if so.) I think I would be reluctant to accept this approach, we had a lot of experience with people who would post hundreds or thousands of rules and they would get a very nasty performance surprise. However, if you look at the code in aws/event-ruler, you will see how the ranges are compiled into automata. These are quite complex automata. But since you have figured out the |
if len(out.steps) > 0 { | ||
for _, state := range out.steps { | ||
for _, fm := range state.fieldTransitions { | ||
for _, v := range fm.vals { |
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.
Because of this loop, this is now O(N) in the number of rules I think?
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.
@timbray Thank you so much for reviewing the code and the feedback. Yes you are right this is O(N). Prolly, I've overlooked something from Event-Ruler implementation. I'll work on this and try to improve. Will keep you posted.
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.
Feel free to hit me with questions if things aren't making sense, there's some complicated stuff in there. My email is public. I'd love for Quamina to have those numeric operators.
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.
Feel free to hit me with questions if things aren't making sense, there's some complicated stuff in there. My email is public. I'd love for Quamina to have those numeric operators.
I've added you to the repo as a collaborator so that the CI/CD will automatically run on PR updates. |
Description
The expression
supports