Hi, The current field update mechanism is not really a field update mechanism. It just looks like that from the outside. DocValues should make true field updates implementable.
Otis -- Solr & ElasticSearch Support http://sematext.com/ On Fri, Mar 29, 2013 at 3:30 PM, Marcin Rzewucki <mrzewu...@gmail.com> wrote: > Hi, > Atomic updates (single field updates) do not depend on DocValues. They were > implemented in Solr4.0 and works fine (but all fields have to be > retrievable). DocValues are supposed to be more efficient than FieldCache. > Why not enabled by default ? Maybe because they are not for all fields and > because of their limitations (a field has to be single-valued, required or > to have default value). > Regards. > > > > On 29 March 2013 17:20, Timothy Potter <thelabd...@gmail.com> wrote: > >> Hi Jack, >> >> I've just started to dig into this as well, so sharing what I know but >> still some holes in my knowledge too. >> >> DocValues == Column Stride Fields (best resource I know of so far is >> Simon's preso from Lucene Rev 2011 - >> >> http://www.slideshare.net/LucidImagination/column-stride-fields-aka-docvalues >> ). >> It's pretty dense but some nuggets I've gleaned from this are: >> >> 1) DocValues are more efficient in terms of memory usage and I/O >> performance for building an alternative to FieldCache (slide 27 is very >> impressive) >> 2) DocValues has a more efficient way to store primitive types, such as >> packed ints >> 3) Faster random access to stored values >> >> In terms of switch-over, you have to re-index to change your fields to use >> DocValues on disk, which is why they are not enabled by default. >> >> Lastly, another goal of DocValues is to allow updates to a single field w/o >> re-indexing the entire doc. That's not implemented yet but I think still >> planned. >> >> Cheers, >> Tim >> >> >> >> On Fri, Mar 29, 2013 at 9:31 AM, Jack Krupansky <j...@basetechnology.com >> >wrote: >> >> > I’m still a little fuzzy on DocValues (maybe because I’m still grappling >> > with how it does or doesn’t still relate to “Column Stride Fields”), so >> can >> > anybody clue me in as to how useful DocValues is/are? >> > >> > Are DocValues simply an alternative to “stored fields”? >> > >> > If so, and if DocValues are so great, why aren’t we just switching Solr >> > over to DocValues under the hood for all fields? >> > >> > And if there are “issues” with DocValues that would make such a complete >> > switchover less than absolutely desired, what are those issues? >> > >> > In short, when should a user use DocValues over stored fields, and vice >> > versa? >> > >> > As things stand, all we’ve done is make Solr more confusing than it was >> > before, without improving its OOBE. OOBE should be job one in Solr. >> > >> > Thanks. >> > >> > P.S., And if I actually want to do Column Stride Fields, is there a way >> to >> > do that? >> > >> > -- Jack Krupansky >>
