-
Notifications
You must be signed in to change notification settings - Fork 7
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
Adding a more robust Criteria interface. #21
Comments
After discussions with various individuals, I'd like to make sure we still have the ability to apply this generic criteria to both batch queries and use "matches()" to verify it against streaming data. That's an extremely powerful feature. The current design means quite a bit of code needs to be changed when new criteria elements are added (such as regex) and it'd be nice to whittle that down a bit. I'm not seeing too many performance issues with the current implementation because generally the visitors (for validating and optimizating) only get done once when the query is sent to the service that's going to be applying it. |
What I mean by performance issues is for evaluating criteria. Currently the only way that can be done is to hook in a visitor that knows how to evaluate all of your criteria. This evaluation would need to be done every time here is a new event in the stream. Only the optimization and validation needs to be done once. |
I mean, right now there's a single optimization that happens with the Node tree before it is turned into the Criteria. The purpose for that is so optimizations can be done once and the resulting Criteria tree can be matched against directly. |
With the new Predicate Criteria, the performance concern isn't an issue. That was mostly related to using the visitor pattern to allow for evaluation of the criteria to return a true/false in a boolean expression tree. |
The current Criteria interface as it stands is decent for doing things such as defining queries and providing simple optimizations to the expression tree.
For usecases where evaluation of an expression needs to processed quickly, the use of the visitor pattern is not well suited. For example in using criteria to analyze data in a stream.
Ideally the two types of criteria could inhabit the same interface, but that would require some redesign of the current implementation. Alternatively, we can provide a separate implementation for this usecase, but this will leave redundant code.
The text was updated successfully, but these errors were encountered: