[jira] [Commented] (LUCENE-3056) Support Query Rewriting Caching

2011-05-02 Thread Simon Willnauer (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13027578#comment-13027578
 ] 

Simon Willnauer commented on LUCENE-3056:
-

Hey chris,

here are some comments:

* I like that you only have to change BooleanQuery to enable this!! nice!
* Can we rename RewriteState into RewriteContext its just more consistent to 
all the other ctx we pass to query and scorer?
* Can we rename DefaultRewriteState into CachingRewriteContext and make a 
RewriteContext that simply does query.rewrite() that way nothing changes by 
default and we can use a static instance in Query#rewrite(IndexReader) maybe as 
an anonymous inner class in Query?
* Can we move CachingRewriteContext into lucene/src/java/org/apache/lucene/util?

This change somewhat depends on LUCENE-3041 since we might wanna pass that 
RewriteContext on a per segment level right? So maybe we should link those 
issues.


 Support Query Rewriting Caching
 ---

 Key: LUCENE-3056
 URL: https://issues.apache.org/jira/browse/LUCENE-3056
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Search
Affects Versions: 4.0
Reporter: Chris Male
 Fix For: 4.0

 Attachments: LUCENE-3056.patch


 Out of LUCENE-3041, its become apparent that using a Visitor / Walker isn't 
 right for caching the rewrites of Querys.  Although we still intend to 
 introduce the Query / Walker for advanced query transformations, rewriting 
 still serves a purpose for very specific implementation detail writing.  As 
 such, it can be very expensive.  So I think we should introduce first class 
 support for rewrite caching.  I also feel the key is to make the caching as 
 transparent as possible, to reduce the strain on Query implementors.
 The TermState idea gave me the idea of maybe making a RewriteState / 
 RewriteCache / RewriteInterceptor, which would be consulted for rewritten 
 Querys.  It would then maintain an internal cache that it would check.  If a 
 value wasn't found, it'd then call Query#rewrite, and cache the result.
 By having this external rewrite source, people could 'pre' rewrite Querys if 
 they were particularly expensive but also common.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3056) Support Query Rewriting Caching

2011-05-02 Thread Chris Male (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13027592#comment-13027592
 ] 

Chris Male commented on LUCENE-3056:


bq. This change somewhat depends on LUCENE-3041 since we might wanna pass that 
RewriteContext on a per segment level right?

Yeah, thats very true.  I'm wondering whether its best to rethink the 
signatures of the #search methods in IS since we need to incorporate both this 
and LUCENE-3041.

I'll upload a patch shortly addressing the other improvements.

 Support Query Rewriting Caching
 ---

 Key: LUCENE-3056
 URL: https://issues.apache.org/jira/browse/LUCENE-3056
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Search
Affects Versions: 4.0
Reporter: Chris Male
 Fix For: 4.0

 Attachments: LUCENE-3056.patch


 Out of LUCENE-3041, its become apparent that using a Visitor / Walker isn't 
 right for caching the rewrites of Querys.  Although we still intend to 
 introduce the Query / Walker for advanced query transformations, rewriting 
 still serves a purpose for very specific implementation detail writing.  As 
 such, it can be very expensive.  So I think we should introduce first class 
 support for rewrite caching.  I also feel the key is to make the caching as 
 transparent as possible, to reduce the strain on Query implementors.
 The TermState idea gave me the idea of maybe making a RewriteState / 
 RewriteCache / RewriteInterceptor, which would be consulted for rewritten 
 Querys.  It would then maintain an internal cache that it would check.  If a 
 value wasn't found, it'd then call Query#rewrite, and cache the result.
 By having this external rewrite source, people could 'pre' rewrite Querys if 
 they were particularly expensive but also common.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org