[Solr Wiki] Update of "Solr1.2" by HossMan

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The following page has been changed by HossMan:
http://wiki.apache.org/solr/Solr1%2e2

------------------------------------------------------------------------------
- [http://www.nabble.com/solr-release-planning-for-1.2-tf3520205.html#a9821749 see discussion]
+ = Solr 1.2 =
  
- /!\ TODO: this is the todo list for what needs to be done before release
+ Solr 1.2 was released on June 6, 2007.
  
+ If you found a link to this page in some documentation it was there to alert you to the fact that it described a feature that was first introduced in the Solr 1.2 release.  Older releases did not have this feature.
  
+  * [http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.2.0/CHANGES.txt Solr 1.2 release notes]
+  * [http://www.apache.org/dyn/closer.cgi/lucene/solr/1.2 Download Solr 1.2]
- == Minor things that should happen ==
-  * "ant package" currently ignores the "client" directory ... should (parts of) it be included?
-  * DONE - [https://issues.apache.org/jira/browse/SOLR-238 SOLR-238] maintainable blurb on the tutorial about which version it's for based on ant variables.
-  * DONE - we need something in the "Upgrading from Solr 1.1" section about how updating can now be controlled by request handlers, but that if installations take advantage of this the Content-type is more strict and the response format has changed.
-  * DONE - [https://issues.apache.org/jira/browse/SOLR-230 SOLR-230] should be done to keep the tutorial nice and portable and eliminate the need for curl
-  * DONE - [http://issues.apache.org/jira/browse/SOLR-170 SOLR-170]
-    * DONE - add the 'sort' parameter to the CommonQueryParameters wiki page
-    * DONE - remove the ';' sort syntax from the StandardRequestHandler wiki page
-    * ?? remove the 'sort' warning from the DisMaxRequestHandler wiki page
  
-  * DONE - Change /update mapping in example solrconfig.xml to use RequestDispatcher
- 
-  * Delete deprecated additions since Solr 1.1
-   * DONE - [http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/request/ContentStream.java ContentStream.java]
-   * DONE - [http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/handler/CommitRequestHandler.java CommitRequestHandler.java]
-   * others????
-  * audit schema.xml and esp solrconfig.xml to figure out what we really want to be "default"
-  * DONE - audit SolrExceptions - with SOLR-204, it will only return a stack trace for errorCode == 500
-    * anything != 500 needs to have a human useful message
-    * a few errors still have new SolrException(1, ... ) and SolrException(2, ... )
-  * audit output of additional URLs now supported, and the interfaces to new handlers since a release implies a longer term commitment to an interface.
-    * DONE? XmlUpdateRequestHandler.
-      * I (ryan) vote that we remove most of the output -- currently it prints the ids as it adds them -- and define the format after the update handler is more generalized.  It shoudl be a format that is easy to be consistent when you write a JSON update handler down the line...
-      * see [http://svn.apache.org/viewvc?view=rev&revision=533556 rev533556]  The response format is now: {{{
-  Posting file monitor2.xml to http://localhost:8983/solr/update
-  <?xml version="1.0" encoding="UTF-8"?>
-  <response>
-  <lst name="responseHeader"><int name="status">0</int><int name="QTime">5</int></lst>
-  </response>
- }}} This is the equivolent information to solr1.1, and will easily be supported in the future.  Solr1.1 format: {{{
-  <result status=\"0\"></result>
- }}}
-    * The o.a.s.handler.admin.* classes all have output that would be nice to format with XSLT.  Can someone with XLST experience look at the output and make sure it would be easy to style (down the line)
-  * DONE - [https://issues.apache.org/jira/browse/SOLR-246 SOLR-246] change the LukeRequestHandler such that top terms are optional.  Currently the performance of this request handler is really bad for large indexes, when all that was desired were the field names/types.
- 
-  * Simple patches
-   * DONE - http://issues.apache.org/jira/browse/SOLR-211 
-   * http://issues.apache.org/jira/browse/SOLR-60 ?
-     * (ryan) I looked into what deprecating the overwriteCommitted/overwritePending would mean...  I'm not sure there is a simple way to do that.  I think the best approach may be to deprecate the entire AddUpdateCommand in favor of something like the IndexDocumentCommand in [https://issues.apache.org/jira/browse/SOLR-139 SOLR-139]... but that is definitely after 1.2
- 
-  * Do what we can to update the front page and features page... this is the first release since graduation from the incubator, and we should take advantage as best we can of all the people that will see announcements and quickly glance at these pages.
- 
-  * Mock test framework?  We need to do one of three things:
-    * keep easymock.jar?  make sure NOTICE.txt is adequate
-    * switch to jmock.jar?
-    * remove easymock.jar?
- 
- 
- == perhaps ==
-  * DONE [http://issues.apache.org/jira/browse/SOLR-204 SOLR-204]  This would give consistent error handling for /select?qt=xxx  -- this is only important to do now because it changes something in solrconfig.xml that was added since 1.1.  It seems better to have a dispatcher configuration group: {{{
-   <requestDispatcher handleSelect="true" >
-     <requestParsers enableRemoteStreaming="false" multipartUploadLimitInKB="2048" />
-   </requestDispatcher>
- }}} rather then: {{{
- <requestDispatcher handleSelect="true" />
- <requestParsers enableRemoteStreaming="false" multipartUploadLimitInKB="2048" /> 
- }}}
- 
-  * DONE [https://issues.apache.org/jira/browse/SOLR-227 SOLR-227] audit schema.xml duplicate field definition behavior.  As is {{{
-   <fieldType name="aaa"  ... />
-   <fieldType name="aaa"  ... />
- 
-   <field name="bbb"  ... />
-   <field name="bbb"  ... />
- 
-   <dynamicField name="ccc_*"  ... />
-   <dynamicField name="ccc_*"  ... />
- }}} quietly continues -- tossing out the first definition.  This should add a severe error and optionally abort (using SOLR-179)
- 
-  * DONE - Consider upgrading lucene versions after an audit of the changes.  there have been some good bug fixes and optimizations.
- 
- == would be nice ==
- 
-  * DONE - [http://issues.apache.org/jira/browse/SOLR-179 SOLR-179]
-  * DONE - [http://issues.apache.org/jira/browse/SOLR-162 SOLR-162]
-   * DONE - If that gets in, we should remove [http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/handler/IndexInfoRequestHandler.java IndexInfoRequestHandler.java] 
-  * DONE - [http://issues.apache.org/jira/browse/SOLR-212 SOLR-212] - direct connection
-  * DONE - [http://issues.apache.org/jira/browse/SOLR-181 SOLR-181] - required fields
- 
- 
- == maybe, but not too important ==
-  * perhaps refactor DisMaxRequestHandler.java and StandardRequestHandler.java to o.a.s.handler - leave a deprecated extended class at the old location.
-  * DONE - maybe change "Support for Dynamic Result Grouping and Filtering" to "Support for filtering and faceting" or something like that.  "Result Grouping" gets folks excited about something that else...
-  * Tutorial update would be nice, but might not be time.
-  * New logo
-  * DONE - [http://issues.apache.org/jira/browse/SOLR-224 SOLR-224] - PhoneticFilterFactory 
-  * ??? [http://issues.apache.org/jira/browse/SOLR-128 SOLR-128] include newer version of jetty
-