Hi Shawn, ES has the same thing. You're right that no 'id' is needed when adding a document.
But lucene has updateDocument: https://lucene.apache.org/core /6_4_0/core/org/apache/lucene/index/IndexWriter.html#updateD ocument-org.apache.lucene.index.Term-java.lang.Iterable- ? Or that doesn't need a commit before deleting docs by Term, so it can atomically delete+insert ? So how do solr/es connect the internal docId to the outside primary-key (to support get,delete) ? Or by just storing/indexing the primary-key in a field ? Thanks, Dorian On Fri, Apr 28, 2017 at 10:34 PM, Shawn Heisey <apa...@elyograg.org> wrote: > On 4/28/2017 6:16 AM, Dorian Hoxha wrote: > > I searched for this on mailing-list,issues etc, but couldn't find any > > post. > > > > So, why not have the possibility of <composite_id> ? > > Or nobody cared enough to implement it ? Or no gains ? > > To my knowledge, and I hope someone can correct me if I'm wrong, Lucene > generally has absolutely no concept of a primary key at all, much less > one that's composite. At its core, Lucene won't complain if you index > the same document twice -- both copies will be present. > > Solr (and probably a LOT of user-written Lucene code before that) > introduced the concept of a uniqueKey field. When a duplicate document > is indexed to Solr, it is Solr that finds/deletes the original, not > Lucene. I feel quite confident in saying that ES has the same > functionality, though I have not confirmed it. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
