Bram: see: https://issues.apache.org/jira/browse/LUCENE-4258 I'm sure the people working on this would gladly get all the help they can. WARNING: I suspect (although I haven't looked myself) that this is very hairy code <G>.
bq: Making all fields stored is simply not possible from a performance point of view I'll challenge this statement a bit, knowing full well that I don't understand your problem space just by saying I've seen some pretty big, high-throughput installations go ahead and store all the fields and use them for atomic updates. As in billions of documents. And note that "index size" as it relates to storing content is orthogonal to searching. By that I mean the index bloat you get when storing fields doesn't really impact search memory requirements much, the stored data is kept in separate files and only assembled for docs as you return them (i.e. a page worth). But _everyone_ will heave a sigh of relief whtn LUCENE-4258 gets into the code (if it does). Note that the "Fix version" of 4.4 just means "sometime after 4.3), I pretty much guarantee it won't be in place for 4.4. I think the need for this is increasing as Solr (and especially SolrCloud) is having larger and larger document sets thrown at it. Best Erick Best Erick On Mon, Jul 8, 2013 at 7:00 AM, Bram Van Dam <bram.van...@intix.eu> wrote: > Howdy, > > Atomic updates only work on stored fields. When submitting an update, any > non-stored fields are apparently emptied. Making all fields stored is simply > not possible from a performance point of view in my case. Neither is > resubmitting all fields. > > Are there any plans to change this behaviour in the future? I don't know how > this works internally, but I suspect that Solr uses get-delete-insert > semantics to "update" the document in Lucene. Would it be technically > feasible to add *real* update mechanisms to solr/lucene? > > If anyone is working on this, I'd like to volunteer some of my time to help > out. > > Thanks, > > - Bram
