What you haven't really explained is why you care. The only hint I see is that you don't want to store the redundant data of your composite key as both individual fields and a concatenated <uniqueKey>.
This feels like a whole lot of effort for no particularly good reason. Unless you have a bazillion _very_ short docs, concatenating the parts together in your <uniqueKey> field is unlikely to be of measurable consequence. If you have _measurements_ showing that's not true, it's another story. Assuming I'm on the right path here, I'd guess there are much more valuable things you could spend engineering time on than the rabbit hole of trying to work around Solr's way of dealing with <uniqueKey> ;).. Best, Erick On Sat, Apr 29, 2017 at 11:38 AM, Dorian Hoxha <dorian.ho...@gmail.com> wrote: > @Yonik Thanks, makes sense. > > @Walter > > After reading the cwiki page on update request processor looks like you > can't modify the GET/DELETE handlers, right ? > Because I want to NOT index/store the 'id' field, so clients/solr-cloud > (which needs /get) continue to work normally but internally 'id' appears > only in translog. > And I need to do something similar for GET/DELETE. > > How to do that ? > > Regards, > Dorian > > On Sat, Apr 29, 2017 at 8:04 PM, Walter Underwood <wun...@wunderwood.org> > wrote: >> >> If you do want a composite key in Solr, you could use an update request >> processor script to make it out of the multiple fields. >> >> wunder >> Walter Underwood >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >> >> On Apr 29, 2017, at 11:02 AM, Yonik Seeley <ysee...@gmail.com> wrote: >> >> On Sat, Apr 29, 2017 at 1:45 PM, Dorian Hoxha <dorian.ho...@gmail.com> >> wrote: >> >> @Yonik >> >> Thanks makes sense. So this means that the 'id' need to be indexed(is >> always?), (so you can get/update/delete docs not in translog), right ? >> >> >> In Solr, yes. In Lucene, only if you want lookup-by-id to be fast, or >> if you want to use updateDocument with an indexed term for overwriting >> documents. >> >> -Yonik >> >> >> On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley <ysee...@gmail.com> wrote: >> >> >> Solr doesn't use Lucene for RT GET, it uses it's transaction log. >> Only when the document is not found in the transaction log will it go >> and consult the lucene index (which can only search as of the last >> commit). >> >> -Yonik >> >> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha <dorian.ho...@gmail.com> >> wrote: >> >> I know all that. My point is, lucene is NRT, while GET is RT (in both >> ES/SOLR). How does lucene return the right document (Term Query) before >> doing a commit on GET ? >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
