Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Sun, 19 Feb 2012 16:32:36 +0000 (UTC)
From: "Uwe Schindler (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <2052375709.487.1329669156879.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1761253802.128.1329648994313.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-3141) Deprecate OPTIMIZE command in Solr
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/SOLR-3141?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13211=
400#comment-13211400 ]=20

Uwe Schindler commented on SOLR-3141:
-------------------------------------

We can even handle that:

If somebody passes optimize=3Dtrue to the update request handle, we dont do=
 anything (no optimize) and instead print a warning message to the log sayi=
ng, that optimize was disabled in Luecen because it has no positive effect =
on most installations. It should also metion, that there is a new forceMerg=
e, but people should not call it unless they exactly know what they are doi=
ng.

The above examples and a lot of more "howtos" on the web make the users thi=
nk, they have to optimize (after every single add). After that they complai=
n how slow solr is. Is this really what you want.

The FIZ Karslruhe eSciDoc projects develops the so called Europeana project=
, which is supposed to index all cultural content from Europe. They are usi=
ng Fedora as repository, so the above issue was like a no-go for them to us=
e GSearch (based on Solr). If you have so many misinformation about optimiz=
e on the net, the most reasonable approach is to simply disable the feature=
 in quesion to prevent further harm.

People that rely on optimize (because they want their statistics 100% corre=
ct) will get informed by the warning messages in the logs. For them its alm=
ost a one-line code change in their Solr client. If they dont do it, they w=
ill also not be disaapointed, because:=20

bq. There is less of a slowdown - but it's certainly still there

So they would in most cases not even recognizing because new versions of so=
lr will bring other improvements.
               =20
> Deprecate OPTIMIZE command in Solr
> ----------------------------------
>
>                 Key: SOLR-3141
>                 URL: https://issues.apache.org/jira/browse/SOLR-3141
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>    Affects Versions: 3.5
>            Reporter: Jan H=C3=B8ydahl
>              Labels: force, optimize
>             Fix For: 3.6
>
>
> Background: LUCENE-3454 renames optimize() as forceMerge(). Please read t=
hat issue first.
> Now that optimize() is rarely necessary anymore, and renamed in Lucene AP=
Is, what should be done with Solr's ancient optimize command?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira

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