Personally I'd leave it as "id" - and adjust your other domain specific field name to something else. Why? Keep Solr and other potential tools from having issues. I don't know exactly what may break, but I'd rather keep things straightforward.
Erik > On Feb 6, 2017, at 02:33, Matthias X Falkenberg <mfalk...@de.ibm.com> wrote: > > Hi Susheel, > > My question is about the name of the "uniqueKey" field rather than the > composition of its values. By default, Solr uses a field with the name > "id". For reasons of ambiguity with the applications in my environment, I > am considering to change the field name to, for example, "docId". Is that > what you have also done for your compound keys? > > One important aspect to consider after using a "uniqueKey" with a > different name is > http://lucene.apache.org/solr/6_3_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html > : "This class assumes the id field for your documents is called 'id' - if > this is not the case, you must set the right name with > setIdField(String)." > > I am wondering whether there are more details or pitfalls that I should be > aware of? > > Mit freundlichen Grüßen / Kind regards, > > Matthias Falkenberg > > Team Lead - IBM Digital Experience Development > IBM Watson Content Hub, IBM WebSphere Portal, IBM Web Content Manager > IBM Deutschland Research & Development GmbH / Vorsitzende des > Aufsichtsrats: Martina Koederitz > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, > HRB 243294 > > > > From: Susheel Kumar <susheel2...@gmail.com> > To: solr-user@lucene.apache.org > Date: 05-02-17 03:21 AM > Subject: Re: Issues with uniqueKey != id? > > > > Hello, > > So far in my experience haven't come across scenario where unique key/id > is > not required. Most of the times, I have put combination of few fields > like aggregate > or compound keys <https://en.wikipedia.org/wiki/Compound_key>. (e.g. > organization_id + employee_id etc.). The reason it makes sense to have > some form of unique key is two fold > a) if there is no unique key, it kind of become impossible to update any > existing records since you can't uniquely identify them which means your > index will keep growing > b) If no unique key then when you return search results, you wouldn't > have > anything to relate with other/external system > > Sometime you may have time-series data in which case may be timestamp or > combination of timestamp / other field may make sense but yes Unique key > is not mandatory. > > Thanks, > Susheel > > On Fri, Feb 3, 2017 at 11:49 AM, Matthias X Falkenberg > <mfalk...@de.ibm.com> > wrote: > >> Howdy, >> >> In the Solr Wiki I stumbled upon a somewhat vague statement on the >> uniqueKey: >> >>> https://wiki.apache.org/solr/SchemaXml#The_Unique_Key_Field >>> It shouldn't matter whether you rename this to something else (and >> change the <uniqueKey> value), but occasionally it has in the past. We >> recommend that you just leave this definition alone. >> >> I'd be very grateful for any positive or negative experiences with >> "uniqueKey" not being set to "id" - especially if your experiences are >> related to Solr 6.2.1+. >> >> Many thanks, >> >> Matthias Falkenberg >> >> IBM Deutschland Research & Development GmbH / Vorsitzende des >> Aufsichtsrats: Martina Koederitz >> Geschäftsführung: Dirk Wittkopp >> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht > Stuttgart, >> HRB 243294 >> >> > > > >
