[jira] Updated: (SOLR-127) Make Solr more friendly to external HTTP caches
[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Peuss updated SOLR-127: -- Attachment: HTTPCaching.patch Make Solr a bit more friendly for HTTP caches. Make Solr more friendly to external HTTP caches --- Key: SOLR-127 URL: https://issues.apache.org/jira/browse/SOLR-127 Project: Solr Issue Type: Wish Reporter: Hoss Man Attachments: HTTPCaching.patch an offhand comment I saw recently reminded me of something that really bugged me about the serach solution i used *before* Solr -- it didn't play nicely with HTTP caches that might be sitting in front of it. at the moment, Solr doesn't put in particularly usefull info in the HTTP Response headers to aid in caching (ie: Last-Modified), responds to all HEAD requests with a 400, and doesn't do anything special with If-Modified-Since. t the very least, we can set a Last-Modified based on when the current IndexReder was open (if not the Date on the IndexReader) and use the same info to determing how to respond to If-Modified-Since requests. (for the record, i think the reason this hasn't occured to me in the 2+ years i've been using Solr, is because with the internal caching, i've yet to need to put a proxy cache in front of Solr) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-127) Make Solr more friendly to external HTTP caches
[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526136 ] Thomas Peuss commented on SOLR-127: --- I have not found out (OK, I tried it only 10 minutes ;-) ) where this HEAD requests get blocked. Should be easy to do if you find the right location Make Solr more friendly to external HTTP caches --- Key: SOLR-127 URL: https://issues.apache.org/jira/browse/SOLR-127 Project: Solr Issue Type: Wish Reporter: Hoss Man Attachments: HTTPCaching.patch an offhand comment I saw recently reminded me of something that really bugged me about the serach solution i used *before* Solr -- it didn't play nicely with HTTP caches that might be sitting in front of it. at the moment, Solr doesn't put in particularly usefull info in the HTTP Response headers to aid in caching (ie: Last-Modified), responds to all HEAD requests with a 400, and doesn't do anything special with If-Modified-Since. t the very least, we can set a Last-Modified based on when the current IndexReder was open (if not the Date on the IndexReader) and use the same info to determing how to respond to If-Modified-Since requests. (for the record, i think the reason this hasn't occured to me in the 2+ years i've been using Solr, is because with the internal caching, i've yet to need to put a proxy cache in front of Solr) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-127) Make Solr more friendly to external HTTP caches
[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Peuss updated SOLR-127: -- Attachment: HTTPCaching.patch Solr now responds nicely to HEAD-requests. Make Solr more friendly to external HTTP caches --- Key: SOLR-127 URL: https://issues.apache.org/jira/browse/SOLR-127 Project: Solr Issue Type: Wish Reporter: Hoss Man Attachments: HTTPCaching.patch, HTTPCaching.patch an offhand comment I saw recently reminded me of something that really bugged me about the serach solution i used *before* Solr -- it didn't play nicely with HTTP caches that might be sitting in front of it. at the moment, Solr doesn't put in particularly usefull info in the HTTP Response headers to aid in caching (ie: Last-Modified), responds to all HEAD requests with a 400, and doesn't do anything special with If-Modified-Since. t the very least, we can set a Last-Modified based on when the current IndexReder was open (if not the Date on the IndexReader) and use the same info to determing how to respond to If-Modified-Since requests. (for the record, i think the reason this hasn't occured to me in the 2+ years i've been using Solr, is because with the internal caching, i've yet to need to put a proxy cache in front of Solr) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-127) Make Solr more friendly to external HTTP caches
[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Peuss updated SOLR-127: -- Attachment: HTTPCaching.patch Some code cleanup and a fixed typo. Make Solr more friendly to external HTTP caches --- Key: SOLR-127 URL: https://issues.apache.org/jira/browse/SOLR-127 Project: Solr Issue Type: Wish Reporter: Hoss Man Attachments: HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch an offhand comment I saw recently reminded me of something that really bugged me about the serach solution i used *before* Solr -- it didn't play nicely with HTTP caches that might be sitting in front of it. at the moment, Solr doesn't put in particularly usefull info in the HTTP Response headers to aid in caching (ie: Last-Modified), responds to all HEAD requests with a 400, and doesn't do anything special with If-Modified-Since. t the very least, we can set a Last-Modified based on when the current IndexReder was open (if not the Date on the IndexReader) and use the same info to determing how to respond to If-Modified-Since requests. (for the record, i think the reason this hasn't occured to me in the 2+ years i've been using Solr, is because with the internal caching, i've yet to need to put a proxy cache in front of Solr) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-335) solrj and ping / PingRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526195 ] Bill Au commented on SOLR-335: -- Until there is a PingRequestHandler, a simple work-around would be to pass in the required parameter for the standard request handler, ie q=solrpingquery. This is what the admin jsp does. I would like to provide a patch to fix the broken ping function in SolrJ. Should I attach it here or open a new bug. If I attach it here, we can keep this bug open until we have a PingRequestHandler. solrj and ping / PingRequestHandler --- Key: SOLR-335 URL: https://issues.apache.org/jira/browse/SOLR-335 Project: Solr Issue Type: Bug Components: clients - java Reporter: Ryan McKinley Priority: Minor Solrj needs to talk to a PingRequestHandler see: http://www.nabble.com/-Solrj--Documentation---SolrServer-Ping-tf4246988.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-352) UpdateRequest is duplicating commit and optimize requests
[ https://issues.apache.org/jira/browse/SOLR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Au updated SOLR-352: - Attachment: solr-352.patch Patch to remove commit/optimize query args since the request already contain an commit/optimize XML message in the POST body. UpdateRequest is duplicating commit and optimize requests - Key: SOLR-352 URL: https://issues.apache.org/jira/browse/SOLR-352 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Bill Au Assignee: Bill Au Priority: Minor Attachments: solr-352.patch UpdateRequest current sets both query args and a update XML message in the POST body. This causes Solr to do two commit/optimize for each commit/optimize request sent in by SolrJ. I will be attaching a patch to remove the commit/optimize query args. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-335) solrj and ping / PingRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526198 ] Ryan McKinley commented on SOLR-335: attach here seems fine. Lets keep this open till there is a PingRequestHandler. solrj and ping / PingRequestHandler --- Key: SOLR-335 URL: https://issues.apache.org/jira/browse/SOLR-335 Project: Solr Issue Type: Bug Components: clients - java Reporter: Ryan McKinley Priority: Minor Solrj needs to talk to a PingRequestHandler see: http://www.nabble.com/-Solrj--Documentation---SolrServer-Ping-tf4246988.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-350: --- Attachment: SOLR-350-MultiCore.patch Here is a quick sketch of what I think the multicore management/interface should look like. Essentially, it works like this: A. If you do nothing, solr keeps working as it is - it has a little extra checking at startup and each requests only makes an extra if( singlecore != null ) call B. If you put a multicore.xml file in the startup instanceDir, a multicore registry will be initialized. Each call to the SolrDispatchFilter will select the core (from a synchronized map). Using the default core does not require a synchronized map lookup. In the attached patch, you select the core from the path: http://host:port/context/handlerpath -- uses default core http://host:port/context/@core0/handlerpath -- uses core0 http://host:port/context/@core1/handlerpath -- uses core1 This assumes handler names will not start with '@' (perhaps we should make it a requirement that handler names don't start with any punctuation? this would leave open special characters in the future?) This still needs a servlet or request handler to manage core manipulation (load, restart, etc). Since it handles functions across handlers, it should probably be a servlet, but that makes it difficult to use the wt=json/xml stuff. NOTE -- the core management stuff is untested, I'm attaching it now because I don't have much time to work on it and hopefully someone else can carry on. Parts of this patch clean up things from SOLR-215. Unless there is much movement on this issue, I'd like to commit that part in a few days. Manage Multiple SolrCores - Key: SOLR-350 URL: https://issues.apache.org/jira/browse/SOLR-350 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-350-MultiCore.patch In SOLR-215, we enabled support for more then one SolrCore - but there is no way to use them yet. We need to make some interface to manage, register, modify avaliable SolrCores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526207 ] Yonik Seeley commented on SOLR-350: --- I assume core management stuff needs to be persistent if you add a core via the REST api, and the server restarts, you want it to still be there. So should multicore.xml be changed and written back in this case? Manage Multiple SolrCores - Key: SOLR-350 URL: https://issues.apache.org/jira/browse/SOLR-350 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-350-MultiCore.patch In SOLR-215, we enabled support for more then one SolrCore - but there is no way to use them yet. We need to make some interface to manage, register, modify avaliable SolrCores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526210 ] Ryan McKinley commented on SOLR-350: Yes, persistence seems like a good option. For the case where you are updating a live schema it may not make sense though. tempCore = load new core defaultCore = tempCore (close old core when all requests have finished) Manage Multiple SolrCores - Key: SOLR-350 URL: https://issues.apache.org/jira/browse/SOLR-350 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-350-MultiCore.patch In SOLR-215, we enabled support for more then one SolrCore - but there is no way to use them yet. We need to make some interface to manage, register, modify avaliable SolrCores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-352) UpdateRequest is duplicating commit and optimize requests
[ https://issues.apache.org/jira/browse/SOLR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526213 ] Bill Au commented on SOLR-352: -- Ryan, I am gettign a NullPointerException when I tried you patch: java.lang.NullPointerException at org.apache.solr.common.util.ContentStreamBase$StringStream.init(ContentStreamBase.java:137) at org.apache.solr.client.solrj.util.ClientUtils.toContentStreams(ClientUtils.java:59) at org.apache.solr.client.solrj.request.UpdateRequest.getContentStreams(UpdateRequest.java:134) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:113) at org.apache.solr.client.solrj.request.UpdateRequest.process(UpdateRequest.java:199) at org.apache.solr.client.solrj.impl.BaseSolrServer.commit(BaseSolrServer.java:79) at org.apache.solr.client.solrj.impl.BaseSolrServer.commit(BaseSolrServer.java:68) at _jsp._solrjCommit__jsp._jspService(solrjCommit.jsp:12) at com.caucho.jsp.JavaPage.service(JavaPage.java:60) at com.caucho.jsp.Page.pageservice(Page.java:570) at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:179) at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:209) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520) at com.caucho.util.ThreadPool.run(ThreadPool.java:442) at java.lang.Thread.run(Thread.java:595) UpdateRequest is duplicating commit and optimize requests - Key: SOLR-352 URL: https://issues.apache.org/jira/browse/SOLR-352 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Bill Au Assignee: Bill Au Priority: Minor Attachments: solr-352.patch, solr-352.patch UpdateRequest current sets both query args and a update XML message in the POST body. This causes Solr to do two commit/optimize for each commit/optimize request sent in by SolrJ. I will be attaching a patch to remove the commit/optimize query args. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DirectSolrConnection, write.lock and Too Many Open Files
On Sep 10, 2007, at 1:56 PM, Mike Klaas wrote: I'm a little worried about Solr getting a bad rap for being buggy or not well-documented due to people trying to use it embeddedly. It seems that we need to do one of two things: 1. Someone lead the effort to clean up and organize the situation, develop and test the relevant api, and document it to the standards of the rest of Solr. 2. Remove references to embedding Solr (including out-of-date wiki pages) if we do not have a maintainer for this functionality. We have a desktop app in alpha now that uses Solr as its data store backend via DirectSolrConnection. It makes a lot of sense in our app especially as the web-app side of the app is also built on Solr. We have a lot of people banging on the code and other than the thread lock issue Adrian and I mentioned, there's been absolutely no problem -- it's fast, stable, relatively low overhead, x-platform and does exactly what we need. I would volunteer to be the DSC maintainer as I probably use it the most, but unfortunately I am not a competent java dev (Ryan can attest to this.) I will volunteer to clean up the end user docs, specifically I owe the wiki a non-objc version of the JNI code.
Re: DirectSolrConnection, write.lock and Too Many Open Files
On 10-Sep-07, at 12:32 PM, Brian Whitman wrote: On Sep 10, 2007, at 1:56 PM, Mike Klaas wrote: I'm a little worried about Solr getting a bad rap for being buggy or not well-documented due to people trying to use it embeddedly. It seems that we need to do one of two things: 1. Someone lead the effort to clean up and organize the situation, develop and test the relevant api, and document it to the standards of the rest of Solr. 2. Remove references to embedding Solr (including out-of-date wiki pages) if we do not have a maintainer for this functionality. We have a desktop app in alpha now that uses Solr as its data store backend via DirectSolrConnection. It makes a lot of sense in our app especially as the web-app side of the app is also built on Solr. We have a lot of people banging on the code and other than the thread lock issue Adrian and I mentioned, there's been absolutely no problem -- it's fast, stable, relatively low overhead, x-platform and does exactly what we need. Have you tried setting the write lock to simple (solr trunk)? I would volunteer to be the DSC maintainer as I probably use it the most, but unfortunately I am not a competent java dev (Ryan can attest to this.) I will volunteer to clean up the end user docs, specifically I owe the wiki a non-objc version of the JNI code. Thanks! -Mike
[jira] Commented: (SOLR-335) solrj and ping / PingRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526237 ] Bill Au commented on SOLR-335: -- It turns out that in the Solr response for a ping is neither a response or result but a solr: ?xml-stylesheet type=text/xsl href=ping.xsl? solr ping /ping /solr Since the response has no useful information, I will put an empty NamedList in SolrPingResponse. solrj and ping / PingRequestHandler --- Key: SOLR-335 URL: https://issues.apache.org/jira/browse/SOLR-335 Project: Solr Issue Type: Bug Components: clients - java Reporter: Ryan McKinley Priority: Minor Solrj needs to talk to a PingRequestHandler see: http://www.nabble.com/-Solrj--Documentation---SolrServer-Ping-tf4246988.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-139: --- Attachment: Eriks-ModifiableDocument.patch applies to /trunk Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, SOLR-269+139-ModifiableDocumentUpdateProcessor.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-352) UpdateRequest is duplicating commit and optimize requests
[ https://issues.apache.org/jira/browse/SOLR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526283 ] Ryan McKinley commented on SOLR-352: I just added some docs to: http://wiki.apache.org/solr/Solrj Essentially, you can work with the UpdateRequest directly and use options that are not available in the SolrServer interface. SolrServer server = ... UpdateRequest req = new UpdateRequest(); req.setAction( UpdateRequest.ACTION.COMMIT, false, false ); req.add( docs ); UpdateResponse rsp = req.process( server ); UpdateRequest is duplicating commit and optimize requests - Key: SOLR-352 URL: https://issues.apache.org/jira/browse/SOLR-352 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Bill Au Assignee: Bill Au Priority: Minor Attachments: solr-352.patch, solr-352.patch UpdateRequest current sets both query args and a update XML message in the POST body. This causes Solr to do two commit/optimize for each commit/optimize request sent in by SolrJ. I will be attaching a patch to remove the commit/optimize query args. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-352) UpdateRequest is duplicating commit and optimize requests
[ https://issues.apache.org/jira/browse/SOLR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526284 ] Ryan McKinley commented on SOLR-352: Note, in solr, this is starting the commit with a request parameter, not commit/ /update?commit=true with post data: add ... /add UpdateRequest is duplicating commit and optimize requests - Key: SOLR-352 URL: https://issues.apache.org/jira/browse/SOLR-352 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Bill Au Assignee: Bill Au Priority: Minor Attachments: solr-352.patch, solr-352.patch UpdateRequest current sets both query args and a update XML message in the POST body. This causes Solr to do two commit/optimize for each commit/optimize request sent in by SolrJ. I will be attaching a patch to remove the commit/optimize query args. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-334) pluggable query parsers
[ https://issues.apache.org/jira/browse/SOLR-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526339 ] Yonik Seeley commented on SOLR-334: --- OK, my next step is to do tests for all these new functions provided no one sees an issue with the general approach. I chose to stick with VaueSource as the basis for new functions rather than CustomScoreQuery because of greater complexities with weights, scorers, explanations, etc, and performance issues wrt scorers (skipTo, next needing to know deleted docs). pluggable query parsers --- Key: SOLR-334 URL: https://issues.apache.org/jira/browse/SOLR-334 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley One should be able to optionally specify an alternate query syntax on a per-query basis http://www.nabble.com/Using-HTTP-Post-for-Queries-tf3039973.html#a8483387 Many benefits, including avoiding the need to do query parser escaping for simple term or prefix queries. Possible Examples: fq=!term field=myfieldThe Term fq=!prefix field=myfieldThe Prefix q=!qp op=ANDa b q=!xml?xml... // lucene XML query syntax? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-334) pluggable query parsers
[ https://issues.apache.org/jira/browse/SOLR-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-334: -- Comment: was deleted pluggable query parsers --- Key: SOLR-334 URL: https://issues.apache.org/jira/browse/SOLR-334 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley One should be able to optionally specify an alternate query syntax on a per-query basis http://www.nabble.com/Using-HTTP-Post-for-Queries-tf3039973.html#a8483387 Many benefits, including avoiding the need to do query parser escaping for simple term or prefix queries. Possible Examples: fq=!term field=myfieldThe Term fq=!prefix field=myfieldThe Prefix q=!qp op=ANDa b q=!xml?xml... // lucene XML query syntax? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-349) boost query by a function of other fields
[ https://issues.apache.org/jira/browse/SOLR-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526340 ] Yonik Seeley commented on SOLR-349: --- OK, my next step is to do tests for all these new functions provided no one sees an issue with the general approach. I chose to stick with VaueSource as the basis for new functions rather than CustomScoreQuery because of greater complexities with weights, scorers, explanations, etc, and performance issues wrt scorers (skipTo, next needing to know deleted docs). boost query by a function of other fields - Key: SOLR-349 URL: https://issues.apache.org/jira/browse/SOLR-349 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: FunctionQuery.patch, linear_combination.patch User should be able to boost a query by a function of other fields Some background: http://www.nabble.com/boosting-a-query-by-a-function-of-other-fields-tf4387856.html#a12510092 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Delete/deprecate HighlightingUtils?
Mike Klaas wrote: Core request handlers do not use this, favouring the new, almost-identical code in the highlighting package. Deprecate or delete? It is rather simple to upgrade code using this to the new regime. Either way is fine by me. Since it is advanced not really public API stuff, it seems a bit cleaner to just delete. Adding another to the TON of deprecated classes seems OK too...
