[jira] Commented: (SOLR-82) specify default values in the schema
[ http://issues.apache.org/jira/browse/SOLR-82?page=comments#action_12458380 ] Hoss Man commented on SOLR-82: -- only had a chance to skim the patch so far, and i think this aspect from the mailing list is going to be a real issue with indexing performance... : The only change I might make is to have the schema store if it has fields : with default values so that DocumentBuilder.getDoc() does not cycle through : all fields if there aren't any. ... we can add a "Set fieldsWithDefaults" to IndexSchema to quickly determine if there are any fields with defaults DocumentBuilder needs to check and what those fields are. > specify default values in the schema > > > Key: SOLR-82 > URL: http://issues.apache.org/jira/browse/SOLR-82 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley >Priority: Minor > Attachments: defaultValuesPatch.patch > > > It would be nice to specify a default value for a given field in the schema. > Chris Hostetter suggested this in: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01564.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r486976 - /incubator/solr/trunk/CHANGES.txt
If people really want a separate RELEASE_NOTES.txt, we could copy some of this stuff out I suppose. I'm not sure if it's needed at this point though. I also figured out that things like CHANGES/RELEASE_NOTES don't need the ASL too (no one else has it, and arat didn't complain either). -Yonik On 12/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: yonik Date: Wed Dec 13 21:48:58 2006 New Revision: 486976 URL: http://svn.apache.org/viewvc?view=rev&rev=486976 Log: adding intro and release notes type stuff to CHANGES Modified: incubator/solr/trunk/CHANGES.txt Modified: incubator/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/incubator/solr/trunk/CHANGES.txt?view=diff&rev=486976&r1=486975&r2=486976 == --- incubator/solr/trunk/CHANGES.txt (original) +++ incubator/solr/trunk/CHANGES.txt Wed Dec 13 21:48:58 2006 @@ -1,20 +1,12 @@ -# Licensed to the Apache Software Foundation (ASF) under one or more -# contributor license agreements. See the NOTICE file distributed with -# this work for additional information regarding copyright ownership. -# The ASF licenses this file to You under the Apache License, Version 2.0 -# (the "License"); you may not use this file except in compliance with -# the License. You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. + Apache Solr Version 1.1.0-dev-incubating +Release Notes -= Solr Change Log == -$Id$ +Introduction + +Apache Solr is an open source enterprise search server based on the Lucene Java +search library, with XML/HTTP and JSON APIs, hit highlighting, faceted search, +caching, replication, and a web administration interface. It runs in a Java +servlet container such as Tomcat. Apache Solr is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by Apache Lucene. Incubation is required of all @@ -24,6 +16,48 @@ is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. +See http://incubator.apache.org/solr for more information. + + +Getting Started +--- +You need a Java 1.5 VM or later installed. +In this release, there is an example Solr server including a bundled +servlet container in the directory named "example". +See the tutorial at http://incubator.apache.org/solr/tutorial.html + + +$Id$ + +== Release 1.1.0-dev-incubating, MMDD == + +Status +-- +This is the first release since Solr joined the Incubator, and brings many +new features and performance optimizations including highlighting, +faceted browsing, and JSON/Python/Ruby response formats. + + +Upgrading from previous Solr versions +- +Older Apache Solr installations can be upgraded by replacing +the relevant war file with the new version. No changes to +the index format or configuration files are needed. + +The default version of the Solr XML response syntax has been changed to 2.2 +This will affect any clients not explicitly specifying the response version. + +By default, Solr will no longer use a searcher that has not fully warmed, +and requests will block in the meantime. To change back to the previous +behavior of using a cold searcher in the event there is no other +warm searcher, see the useColdSearcher config item in solrconfig.xml + +The XML response format when adding multiple documents to the collection +in a single command has changed to return a single . + + +Detailed Change List + New Features 1. added support for setting Lucene's positionIncrementGap
Re: test release artifacts
Some incubator people have been recommending release notes. It made me think about the discussion we had about calling out non back compatible stuff in CHANGES.txt, and makes me think that should be the release notes. Put a higher level section at the top, with potentially a little more general info and how to migrade, and all the individual changes below. Some projects do it like this. So, a proposed layout for our releases: solr/KEYS.txt solr/1.1/apache-solr-1.1.0-incubating.[zip,tgz,etc] solr/1.1/CHANGES.txt Then the website would be able to link directly to the CHANGES.txt as well as the archives. -Yonik
[jira] Updated: (SOLR-59) Copy request parameters to Solr's response
[ http://issues.apache.org/jira/browse/SOLR-59?page=all ] Yonik Seeley updated SOLR-59: - Attachment: SOLR-59-20061213.patch Ok, updated patch to - bump current & default version to 2.2 - bump version used in tests to 2.2 (added 2.0 to tests where necessary) - changed "name" of the normal doclist returned by the handlers to "response" - other little minor cleanups Bertrand, since you started this issue, I'll let you commit it if you feel comfortable with it :-) > Copy request parameters to Solr's response > -- > > Key: SOLR-59 > URL: http://issues.apache.org/jira/browse/SOLR-59 > Project: Solr > Issue Type: Improvement >Reporter: Bertrand Delacretaz > Attachments: SOLR-59-20061024.patch, SOLR-59-20061102.patch, > SOLR-59-20061103.patch, SOLR-59-20061106-newfiles.tar.gz, > SOLR-59-20061106.patch, SOLR-59-20061213.patch, > SOLR-59-new-files-20061102.tar.gz > > > This patch copies the request parameters (explicit ones only, not the > defaults) to Solr's XML output. > It is not configurable yet, it is enabled by default and adds a > "queryParameters" list to the responseHeader: > > 0 > 1 > > > red > blue > > 10 > 0 > on > solr > > 2.1 > > > The above example includes a multi-valued parameter, "multi". > This might still change a bit, but if someone wants to play with it or > improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-82) specify default values in the schema
[ http://issues.apache.org/jira/browse/SOLR-82?page=all ] Ryan McKinley updated SOLR-82: -- Attachment: defaultValuesPatch.patch This modifies SchemaField.java to keep a "defaultValue" and DocumentBuilder.java makes sure they exist when returning the document. The test is not totally adequate (i'm not so good with XPath yet..) but it does make sure a date specified in the schema exists > specify default values in the schema > > > Key: SOLR-82 > URL: http://issues.apache.org/jira/browse/SOLR-82 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley >Priority: Minor > Attachments: defaultValuesPatch.patch > > > It would be nice to specify a default value for a given field in the schema. > Chris Hostetter suggested this in: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01564.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-82) specify default values in the schema
specify default values in the schema Key: SOLR-82 URL: http://issues.apache.org/jira/browse/SOLR-82 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Priority: Minor It would be nice to specify a default value for a given field in the schema. Chris Hostetter suggested this in: http://www.mail-archive.com/solr-user@lucene.apache.org/msg01564.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: test release artifacts
Sounds like a plan... issues 58,59,78 left. -Yonik On 12/13/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: : Some of the things I think could go in: : https://issues.apache.org/jira/browse/SOLR-79 ... i don't think that's quite ready yet. : https://issues.apache.org/jira/browse/SOLR-78 ...i'll try to have that ready tomorow : https://issues.apache.org/jira/browse/SOLR-70 ...done : https://issues.apache.org/jira/browse/SOLR-69 : -- the more-like-this output looked fine to me (but it was my first : exposure to that lucene feature) did anyone else get a chance to : review it? I haven't reviewed it, personally i don't think we should add new bells and whistles to either of the request handlers just before our first big release without letting them "soak" a bit. : https://issues.apache.org/jira/browse/SOLR-59 ...i think yonik said he's working on the backwards compatibility. : https://issues.apache.org/jira/browse/SOLR-58 ...done, but has a bug that should be fixed.
Re: test release artifacts
: Some of the things I think could go in: : https://issues.apache.org/jira/browse/SOLR-79 ... i don't think that's quite ready yet. : https://issues.apache.org/jira/browse/SOLR-78 ...i'll try to have that ready tomorow : https://issues.apache.org/jira/browse/SOLR-70 ...done : https://issues.apache.org/jira/browse/SOLR-69 : -- the more-like-this output looked fine to me (but it was my first : exposure to that lucene feature) did anyone else get a chance to : review it? I haven't reviewed it, personally i don't think we should add new bells and whistles to either of the request handlers just before our first big release without letting them "soak" a bit. : https://issues.apache.org/jira/browse/SOLR-59 ...i think yonik said he's working on the backwards compatibility. : https://issues.apache.org/jira/browse/SOLR-58 ...done, but has a bug that should be fixed. -Hoss
[jira] Assigned: (SOLR-78) [PATCH] Improved config loading
[ http://issues.apache.org/jira/browse/SOLR-78?page=all ] Hoss Man reassigned SOLR-78: Assignee: Hoss Man I tried to produce an example of the type of thing i'm worried about with the body of a comment getting slurped up ... but i could not -- as far as i can tell that's actually a defect of the DOM parser, the spec says it should be there. Either way it should be safe and easy to check the Node type and only include nodes that aren't comments or processing instructions, i'll try to do that tomorow. > [PATCH] Improved config loading > --- > > Key: SOLR-78 > URL: http://issues.apache.org/jira/browse/SOLR-78 > Project: Solr > Issue Type: Improvement >Reporter: Alexander Saar > Assigned To: Hoss Man >Priority: Minor > Attachments: fixed-config-loading-with-older-parser-versions.patch > > > Solr configuration throws an UnsupportedConfigurationException for > Node.getTextContent() if it is started in server environments that uses older > implementations of the DOM API. This can be improved by checking wich node > type is actually handled an calling the appropriate methods. > A patch that fixes this problem is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r486373 - in /incubator/solr/trunk: ./ src/webapp/resources/admin/
Good catch. IMO, this should be fixed before we cut our release. -Yonik On 12/13/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: Otis, i finally got a chance to try this out, and I'm noticing that while most of hte pages look great, the analysis page isn't displaying the form by default, so if you load "http://localhost:8983/solr/admin/analysis.jsp"; or click the link from the main admin page: "http://localhost:8983/solr/admin/analysis.jsp?highlight=on"; you have no where to go from there. If you know what the URL should look like, and try to type it in explicitly, you get a malformed XML file... http://localhost:8983/solr/admin/analysis.jsp?name=text&highlight=on&val=booo&qval= ...there are too many tags it looks like.
[jira] Reopened: (SOLR-58) Change Admin components to return XML like the rest of the system
[ http://issues.apache.org/jira/browse/SOLR-58?page=all ] Hoss Man reopened SOLR-58: -- analysis.jsp currently isn't working properly ... it doesn't display the form by default, and if you manually create a URl that should work, you get a malformed XML response back. > Change Admin components to return XML like the rest of the system > - > > Key: SOLR-58 > URL: http://issues.apache.org/jira/browse/SOLR-58 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Otis Gospodnetic > Assigned To: Otis Gospodnetic >Priority: Minor > Attachments: SOLR-58.patch > > > I need to expose the admin functionality to an external application. I think > returning admin data as XML may be a good and simple first step towards that. > To do that I think I'll mostly need to modify JSPs (but I haven't had a good > look at Admin GUI yet). From what I saw a few weeks ago when I briefly > looked at this, no Java code will need to be modified. If you have concrete > ideas about how this should be done, please comment before I start next week > (week of October 23rd 2006). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-70) ping.jsp is very naive -- doesn't work with "qt" or any extra query args
[ http://issues.apache.org/jira/browse/SOLR-70?page=all ] Hoss Man resolved SOLR-70. -- Resolution: Fixed commited variation of patch which worked against trunk (with newer XML based pages) > ping.jsp is very naive -- doesn't work with "qt" or any extra query args > > > Key: SOLR-70 > URL: http://issues.apache.org/jira/browse/SOLR-70 > Project: Solr > Issue Type: Bug >Reporter: Hoss Man > Assigned To: Hoss Man >Priority: Critical > Attachments: ping.patch > > > while reviewing SOLR-58 i noticed that ping.jsp is *extremely* naive about > the types of requests it can use to sanity check the index, in particular: >* it treats the first query param that starts with "q" as the query string > (like for example "qt") >* it ignores all other query params > ...this makes it worthless to try and configure anything but the standard > querest handler with no options as your ping URL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: inconsistent name for first DocList of response
: The standard request handler used a name of null, resulting in
:
:
i think that was a cut/paste error, you mean...
...right?
: The JSON/Ruby/Python handler needed a name, and so if the name was
: null, defaulted to "response", resulting in
:
: "response":{"numFound":0,"start":0,"docs":[]}
: documents resulting from the main search. search-results is JSON
: friendly enough, but it's not as javascript friendly.
: You can do something like x.results, but you can't do x.search-results
:
: TODO:
: - pick a name for the doclist... preferences?
: - decide if this name needs to be reverted to it's original for
: backward compatibility (based on version number) yuck. XML folks
: shouldn't be bothered, as it's just an attribute that would normally
: have been ignored. It's more of an issue for JSON output (or
: related).
Well, people parsing the XML might be using XPath to explicitly ask for
//[EMAIL PROTECTED]"search-results"] ... but I doubt it.
if "response" is what the Text based ResponseWriters have been defaulting
too, i would suggest we just make that the explicit name in both
out-of-box handlers, and not worry too much baout hte backwards
compatibility of "search-results" for dismax.
-Hoss
Re: svn commit: r486373 - in /incubator/solr/trunk: ./ src/webapp/resources/admin/
Otis, i finally got a chance to try this out, and I'm noticing that while
most of hte pages look great, the analysis page isn't displaying the form
by default, so if you load
"http://localhost:8983/solr/admin/analysis.jsp"; or click the link from the
main admin page:
"http://localhost:8983/solr/admin/analysis.jsp?highlight=on"; you have no
where to go from there.
If you know what the URL should look like, and try to type it in
explicitly, you get a malformed XML file...
http://localhost:8983/solr/admin/analysis.jsp?name=text&highlight=on&val=booo&qval=
...there are too many tags it looks like.
: Date: Tue, 12 Dec 2006 22:24:48 -
: From: [EMAIL PROTECTED]
: Reply-To: solr-dev@lucene.apache.org
: To: solr-commits@lucene.apache.org
: Subject: svn commit: r486373 - in /incubator/solr/trunk: ./
: src/webapp/resources/admin/
:
: Author: otis
: Date: Tue Dec 12 14:24:47 2006
: New Revision: 486373
:
: URL: http://svn.apache.org/viewvc?view=rev&rev=486373
: Log:
: - SOLR-58: make admin pages return XML and transform them to HTML using XSL
:
: Added:
: incubator/solr/trunk/src/webapp/resources/admin/analysis.xsl
: incubator/solr/trunk/src/webapp/resources/admin/heading.jsp
: incubator/solr/trunk/src/webapp/resources/admin/logging.xsl
: incubator/solr/trunk/src/webapp/resources/admin/meta.xsl
: incubator/solr/trunk/src/webapp/resources/admin/ping.xsl
: incubator/solr/trunk/src/webapp/resources/admin/threaddump.xsl
: Modified:
: incubator/solr/trunk/CHANGES.txt
: incubator/solr/trunk/src/webapp/resources/admin/analysis.jsp
: incubator/solr/trunk/src/webapp/resources/admin/logging.jsp
: incubator/solr/trunk/src/webapp/resources/admin/ping.jsp
: incubator/solr/trunk/src/webapp/resources/admin/threaddump.jsp
:
: Modified: incubator/solr/trunk/CHANGES.txt
: URL:
http://svn.apache.org/viewvc/incubator/solr/trunk/CHANGES.txt?view=diff&rev=486373&r1=486372&r2=486373
: ==
: --- incubator/solr/trunk/CHANGES.txt (original)
: +++ incubator/solr/trunk/CHANGES.txt Tue Dec 12 14:24:47 2006
: @@ -118,6 +118,8 @@
: through multiple threads. Large commits also might be faster (klaas,
SOLR-65)
: 9. Lazy field loading can be enabled via a solrconfig directive. This will
be faster when
: not all stored fields are needed from a document (klaas, SOLR-52)
: +10. Made admin JSPs return XML and transform them with new XSL stylesheets
: +(Otis Gospodnetic, SOLR-58)
:
: Optimizations
: 1. getDocListAndSet can now generate both a DocList and a DocSet from a
:
: Modified: incubator/solr/trunk/src/webapp/resources/admin/analysis.jsp
: URL:
http://svn.apache.org/viewvc/incubator/solr/trunk/src/webapp/resources/admin/analysis.jsp?view=diff&rev=486373&r1=486372&r2=486373
: ==
: --- incubator/solr/trunk/src/webapp/resources/admin/analysis.jsp (original)
: +++ incubator/solr/trunk/src/webapp/resources/admin/analysis.jsp Tue Dec 12
14:24:47 2006
: @@ -1,20 +1,4 @@
: -<%@ page contentType="text/html; charset=utf-8" pageEncoding="UTF-8"%>
: -<%--
: - Licensed to the Apache Software Foundation (ASF) under one or more
: - contributor license agreements. See the NOTICE file distributed with
: - this work for additional information regarding copyright ownership.
: - The ASF licenses this file to You under the Apache License, Version 2.0
: - (the "License"); you may not use this file except in compliance with
: - the License. You may obtain a copy of the License at
: -
: - http://www.apache.org/licenses/LICENSE-2.0
: -
: - Unless required by applicable law or agreed to in writing, software
: - distributed under the License is distributed on an "AS IS" BASIS,
: - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
: - See the License for the specific language governing permissions and
: - limitations under the License.
: ---%>
: +<%@ page contentType="text/xml; charset=utf-8" pageEncoding="UTF-8"
language="java" %>
: <%@ page import="org.apache.lucene.analysis.Analyzer,
: org.apache.lucene.analysis.Token,
: org.apache.lucene.analysis.TokenStream,
: @@ -30,129 +14,86 @@
: <%@ page import="java.io.StringReader"%>
: <%@ page import="java.util.*"%>
:
: -<%-- $Id$ --%>
: -<%-- $Source:
/cvs/main/searching/org.apache.solrolarServer/resources/admin/analysis.jsp,v $
--%>
: -<%-- $Name: $ --%>
: +
:
: -<[EMAIL PROTECTED] file="header.jsp" %>
: +<[EMAIL PROTECTED] file="_info.jsp" %>
:
: <%
:String name = request.getParameter("name");
: - if (name==null || name.length()==0) name="";
: + if (name == null || name.length() == 0) name = "";
:String val = request.getParameter("val");
: - if (val==null || val.length()==0) val="";
: + if (val == null || val.length() == 0) val = "";
:String qval = request.getParameter("qval");
: - if (qval==null || qval.leng
inconsistent name for first DocList of response
I've been patching https://issues.apache.org/jira/browse/SOLR-59
for backward compatibility, and also decided to normalize the name of
the first result set.
The standard request handler used a name of null, resulting in
The JSON/Ruby/Python handler needed a name, and so if the name was
null, defaulted to "response", resulting in
"response":{"numFound":0,"start":0,"docs":[]}
What I just discovered is that the dismax handler *does* use a name...
"search-results":
So... we should really standardize the name of the first list of
documents resulting from the main search. search-results is JSON
friendly enough, but it's not as javascript friendly.
You can do something like x.results, but you can't do x.search-results
TODO:
- pick a name for the doclist... preferences?
- decide if this name needs to be reverted to it's original for
backward compatibility (based on version number) yuck. XML folks
shouldn't be bothered, as it's just an attribute that would normally
have been ignored. It's more of an issue for JSON output (or
related).
On the subject of SOLR-59, the XML output if version=2.2 looks like
0
0
And revers to the original for version<=2.1
0
0
-Yonik
[jira] Commented: (SOLR-81) Add Query Spellchecker functionality
[ http://issues.apache.org/jira/browse/SOLR-81?page=comments#action_12458072 ] Ogün Bilge commented on SOLR-81: Yes exactly as you described. The Fieldnames for the gram fields have to be like this to make it work with SpellChecker: A NGramAnalyzer is enough, i used a WhiteSpacetokenizer as Tokenizer, some other filters and finally the NGramAnaylzer Unfortunately the SpellChecker implementation has a beta state imho. It is not possible to set your own boost factors for the start or end grams. In the current release it is set to start-gram factor 2 , end-gram factor 1 > Add Query Spellchecker functionality > > > Key: SOLR-81 > URL: http://issues.apache.org/jira/browse/SOLR-81 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Otis Gospodnetic >Priority: Minor > > Use the simple approach of n-gramming outside of Solr and indexing n-gram > documents. For example: > > lettuce > let > let ett ttu tuc uce > uce > lett > lett ettu ttuc tuce > tuce > > See: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html > Java clients: SOLR-20 (add delete commit optimize), SOLR-30 (search) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-81) Add Query Spellchecker functionality
[ http://issues.apache.org/jira/browse/SOLR-81?page=comments#action_12458052 ] Otis Gospodnetic commented on SOLR-81: -- Something like this, then? Plus: I'd probably also want to give those word_start* n-grams some boost, though I don't see how to do that in schema.xml yet. > Add Query Spellchecker functionality > > > Key: SOLR-81 > URL: http://issues.apache.org/jira/browse/SOLR-81 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Otis Gospodnetic >Priority: Minor > > Use the simple approach of n-gramming outside of Solr and indexing n-gram > documents. For example: > > lettuce > let > let ett ttu tuc uce > uce > lett > lett ettu ttuc tuce > tuce > > See: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html > Java clients: SOLR-20 (add delete commit optimize), SOLR-30 (search) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
