-
Notifications
You must be signed in to change notification settings - Fork 869
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
add support to lucene module for converting a query to a Lucene QueryWrapperFilter #491
Comments
Another option could be to add something like a "const" method to a filter predicate. Then we can use the dsl to express the static and dynamic parts and QueryDSL could internally create a query with the corresponding filter. |
AbstractLuceneQuery.createQuery() is private. Maybe filter access could be provided on the AbstractLuceneQuery level instead? Something like this maybe public Filter asFilter() {
return new QueryWrapperFilter(createQuery());
} or alternatively just make the access of createQuery public? |
The asFilter implementation looks pretty good. From a Lucene point of view we should only use filters if we want to reuse them, so probably it would make sense to always return a CachingWrapperFilter instance. For further enhancements it would be cool to have the createQuery() method with protected visibility, so subclasses can access it. By the way: what would be the best way to create unit tests for TypedQueries? Should i rely on toString() or should i assert the created Lucene query? |
Probably assert the created Lucene query. |
So protected acces for createQuery() makes perfect sense, or even public access... |
Released in 3.2.4 |
It would be great to have an ability to convert a TypedQuery to a Lucene QueryWrapperFilter. This would enable us to convert queries with a "constant" and a "dynamic" part to a Filter for the "constant" conditions and reuse it between different filters. This would greatly improve query performance in Lucene4. The AbstractLuceneQuery. createQuery() Method is private, so i am not able to implement this functionality by subclassing or delegation.
The text was updated successfully, but these errors were encountered: