Re: solr release planning for 1.2
Yonik Seeley wrote: On 4/5/07, Ryan McKinley [EMAIL PROTECTED] wrote: I'm certainly on board with adding a requestHandler mapping for /update, but i'm not sure how i feel about changing it under the covers ... I'm suggesting we keep /update mapped to SolrUpdateServlet in web.xml, but map: requestHandler name=/update class=solr.XmlUpdateRequestHandler +1 I am not sure what we should do with the DispatchFilter handle-select parameter: init-param param-namehandle-select/param-name param-valuetrue/param-value /init-param Why do we need this parameter? I thought that /select through DispatchFilter would be backward compatible with the servlet's current handling? If that's the case, just have dispatch handle it and be done with it. Since writing this, I added SOLR-204 - this lets you configure if the DispatchFilter will handle select in solrconfig.xml rather then web.xml If the configuration is in solrconfig.xml, we can set the example to use the dispatcher but still leave the option of the 'old' style servlet if that is desired. The only real difference between them is how errors are returned. The dispatcher calls req.sendError( code, msg ) while the servlet writes them out directly (causing them to be hidden by IE/FF) SOLR-204 removes the init-param
Re: solr release planning for 1.2
On 4/28/07, Ryan McKinley [EMAIL PROTECTED] wrote: If the configuration is in solrconfig.xml, we can set the example to use the dispatcher but still leave the option of the 'old' style servlet if that is desired. The only real difference between them is how errors are returned. The dispatcher calls req.sendError( code, msg ) while the servlet writes them out directly (causing them to be hidden by IE/FF) I think only the body of the response changes since the HTTP error codes were already being used for /select Since the body of the response was never really specified, and it wasn't in a parseable format, I think using sendError() could be considered backward compatible. -Yonik
Re: solr release planning for 1.2
I'm certainly on board with adding a requestHandler mapping for /update, but i'm not sure how i feel about changing it under the covers ... I'm suggesting we keep /update mapped to SolrUpdateServlet in web.xml, but map: requestHandler name=/update class=solr.XmlUpdateRequestHandler in solrconfig.xml. The only serious problem i see with that is that /update and /update/ could go to two different places. I'm not sure why web.xml has update mapped to /update/* I am not sure what we should do with the DispatchFilter handle-select parameter: init-param param-namehandle-select/param-name param-valuetrue/param-value /init-param This would have the same error handling (and response codes) for /select?qt=xxx as it does for /path/mapped/in/config BUT if someone wanted to opt-out of that change, they would need to edit web.xml. I think consistent error handling is worth it, but I'm not sure if this would hurt anyone. also gives options for people should bugs be encountered in either code path) yes really need many more new features -- the real question is are there any large concepts currently in progress that should be finished off? The major 'in progress' work still needs attention, so i don't think they are suitable for a near term release. That said, the things I would like to see included are: SOLR-162, SOLR-184, and SOLR-179 All of these are useful to people getting started with solr and helpful debugging tools. I've convinced a bunch of people to use solr and these additions make it much easier for someone to help debug without access to the machine. It is much nicer to have people running official releases then a patched up war I build. And of course: are there any new API type things (config syntax, param names, etc...) since the 1.1 release that we want to tweak? The one thing i can think of is that it would be nice to solidify the handler package as the place that request handlers go. How do you feel about deprecating o.a.s.request.StandardRequestHandler and moving it to o.a.s.handler.StandardRequestHandler -- same for DisMaxRequestHandler we can leave an deprecated extended class in o.a.s.request untill the next release or two. something like: http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/request/ContentStream.java This way anyone extending Standard or Dismax don't need to refactor immediately. ryan
Re: solr release planning for 1.2
I put my (hopeful) todo list at: http://wiki.apache.org/solr/Solr1%2e2
Re: solr release planning for 1.2
Me t.. :-) Just too add my two cents :-) I would rather see a 3 mos release cycle then mega big releases.. cos often times bugs i found were in customer site and manging customers wish... and most customer don't want to run nightly build on production. This is the case in enterprise segment. So I would love to see a regular cycle of release from solr. Off course this shouldn't create too much of a overhead so its takes the fun out of doing a release. I would love to see SOLR-20 but as I remember this is not ready yet. Cheers On 4/3/07, Ryan McKinley [EMAIL PROTECTED] wrote: I want it all!!! If you are thinking within the next week or two, I vote we focus on consistent response format and better error handling. I would suggest that rather then map /update to SolrUpdateServlet, it should use the new update handler framework - returning non 200 response for errors. I would also vote for something like SOLR-179, but i have not heard much feedback from others on that. If the timespan were longer, I would want to get in modifying/updating documents - but that still has a lot of design choices that we should all feel confident about. The other minor things I would like to see soon (but should not affect release) are SOLR-184 and SOLR-176 ryan On 4/3/07, Yonik Seeley [EMAIL PROTECTED] wrote: While it doesn't particularly feel like a natural place to have a release now, it has been 3.5 months since release 1.1, and that was while we were still in the incubator. More frequent releases allows users access to new features in a timely manner without using a nightly build, and thus allows developers more flexibility to change things between releases. So what features / issues do people think we need to resolve before we make a 1.2 release? -Yonik
Re: solr release planning for 1.2
On 4/3/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...So what features / issues do people think we need to resolve before we make a 1.2 release?... I agree that having a non-incubator release would be good, and as long as it's stable I don't care too much about exactly what new features are in it (also because I have little time for helping ATM). -Bertrand
solr release planning for 1.2
While it doesn't particularly feel like a natural place to have a release now, it has been 3.5 months since release 1.1, and that was while we were still in the incubator. More frequent releases allows users access to new features in a timely manner without using a nightly build, and thus allows developers more flexibility to change things between releases. So what features / issues do people think we need to resolve before we make a 1.2 release? -Yonik
Re: solr release planning for 1.2
I want it all!!! If you are thinking within the next week or two, I vote we focus on consistent response format and better error handling. I would suggest that rather then map /update to SolrUpdateServlet, it should use the new update handler framework - returning non 200 response for errors. I would also vote for something like SOLR-179, but i have not heard much feedback from others on that. If the timespan were longer, I would want to get in modifying/updating documents - but that still has a lot of design choices that we should all feel confident about. The other minor things I would like to see soon (but should not affect release) are SOLR-184 and SOLR-176 ryan On 4/3/07, Yonik Seeley [EMAIL PROTECTED] wrote: While it doesn't particularly feel like a natural place to have a release now, it has been 3.5 months since release 1.1, and that was while we were still in the incubator. More frequent releases allows users access to new features in a timely manner without using a nightly build, and thus allows developers more flexibility to change things between releases. So what features / issues do people think we need to resolve before we make a 1.2 release? -Yonik
