Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7864CE7E0 for ; Mon, 3 Dec 2012 10:28:01 +0000 (UTC) Received: (qmail 48230 invoked by uid 500); 3 Dec 2012 10:28:00 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 48077 invoked by uid 500); 3 Dec 2012 10:27:59 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 48035 invoked by uid 99); 3 Dec 2012 10:27:58 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Dec 2012 10:27:58 +0000 Date: Mon, 3 Dec 2012 10:27:58 +0000 (UTC) From: "Adrien Grand (JIRA)" To: dev@lucene.apache.org Message-ID: <1786561594.52714.1354530478897.JavaMail.jiratomcat@arcas> In-Reply-To: <845179721.120980.1353013152386.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (SOLR-4085) Commit-free ExternalFileField MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SOLR-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508629#comment-13508629 ] Adrien Grand commented on SOLR-4085: ------------------------------------ To me ExternalFileField is a convenient (but hacky) way to map documents to floats values in a static index. I understand that it may need to support updates (ReloadCacheRequestHandler) in order to seldom fix values. Commit-free updates support however makes ExternalFileField look like the perfect candidate to support frequent document updates but I don't like the fact that it needs to read the whole file every time (with a java.io.Reader!) and resolve IDs against the top-level reader. Moreover the lack of atomicity makes it different from everything else we have in Lucene and Solr and I imagine people having a scoring function such as if (fieldA > 0) { return fieldB / fieldA } else { return 0 }: this might break badly if fieldA is an ExternalFileField and its valued is modified from 1 to 0 between the first and the second evaluation. I'm also a little worried about the problems you mentioned regarding concurrent reloads. But on the other hand you didn't modify anything outside of ExternalFileField and FileFloatSource so it's perfectly fine with me if Alan or another committer decides this should be committed. > Commit-free ExternalFileField > ----------------------------- > > Key: SOLR-4085 > URL: https://issues.apache.org/jira/browse/SOLR-4085 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis > Affects Versions: 4.1 > Reporter: Mikhail Khludnev > Labels: externalfilefield > Attachments: SOLR-4085.patch > > > Let's reload ExternalFileFields without commit! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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