lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Poulton, Gareth | Gareth | DU" <gareth.poul...@mail.rakuten.com>
Subject RE: Field update (SOLR139, SOLR828)
Date Wed, 05 Oct 2011 01:20:23 GMT
Hi,
The part I'm having difficulty understanding is (and I'm new to Lucene so please be gentle):
why do we need to reindex other fields of the document?
If I update field A, is there any theoretical reason why we need to rebuild (or even *look*
at) the indexes built on fields B or C? Are they in some way inextricably tied to index A
at too fundamental a level to be able to leave them alone?

Thanks,
Gareth

-----Original Message-----
From: Ryan McKinley [mailto:ryantxu@gmail.com] 
Sent: Monday, September 26, 2011 11:45 PM
To: dev@lucene.apache.org
Subject: Re: Field update (SOLR139, SOLR828)

The crux of the problem is that updating a field in lucene requires we reindex the *entire*
document, not just the single field.

The approach in SOLR-139 assumes you have stored all fields, and loads them then reindexes.
 After working with this for a while, it is clear that this kind of approach is better tackled
on the client side -- where you have better knowledge how the fields may be stored, or could
read them from solr if you want.

That said...  there has been some great new work on a different field type that will potentially
be updateable without reindexing the whole document.
http://www.slideshare.net/lucenerevolution/willnauer-simon-doc-values-column-stride-fields-in-lucene
(i'm actually not sure what it is called anymore)

ryan



2011/9/26 Poulton, Gareth | Gareth | DU <gareth.poulton@mail.rakuten.com>:
> Hi,
>
> I’d like to do bulk updating on a single field, i.e. provide a field 
> name once and then a long list of document ids and values to update 
> only that field and leaving the others intact. I noticed SOLR139 / 828.
>
>
>
> If I’m reading this correctly it looks as though it was abandoned 
> three years ago; was this because the authors lost interest, or 
> because some fundamental flaw was discovered in the approach, or 
> something else? Is it currently in a usable state? Is it worth my 
> while trying to make it work or would I be better off doing something 
> from scratch? Any advice would be much appreciated.
>
>
>
> Thanks,
>
>
>
> Gareth Poulton | ポルトン ガレフ
>
> 楽天・開発部・次世代サーチグループ
>
> gareth.poulton@mail.rakuten.com
>
>

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


Mime
View raw message