Skip to content
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

Closed
eawagner opened this issue Jun 22, 2013 · 4 comments
Closed

Adding a more robust Criteria interface. #21

eawagner opened this issue Jun 22, 2013 · 4 comments

Comments

@eawagner
Copy link
Member

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.

@cjnolet
Copy link
Member

cjnolet commented Jul 18, 2013

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.

@eawagner
Copy link
Member Author

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.

@cjnolet
Copy link
Member

cjnolet commented May 17, 2014

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.

@eawagner
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants