Please don’t mess with _version_, that’s used internally for optimistic locking. I don’t have a clue, really, whether changing the definition will be deleterious or not.
OTOH, that field was presumably defined by people who put the use of _version_ in in the first place, so changing it is just asking for trouble. In general, any variable defined with before-and-after underscores should be left strictly alone. Otherwise you’re on the right track. Best, Erick > On Aug 13, 2020, at 8:46 AM, Akshay Murarka <aks...@saavn.com> wrote: > > So to make things clear, belows what I am expecting > > I have a document with a unique id field lets say "uniqueID". > This document has both stored/indexed and not stored/ not indexed fields > Currently I have my pop values in external files but I will instead define > a new field in schema (popVal) which will not be stored or indexed and have > docValues=true. > I am also moving _version_ field to indexed=false and stored=false, since I > don't have any case where I retrieve it and use it for searching. Just > hoping doing this doesn't cause any issues with updates in general (I read > that keeping this as not stored and not indexed is recommended since solr 7) > > Regards, > Akshay > > On Thu, Aug 13, 2020 at 4:53 PM Erick Erickson <erickerick...@gmail.com> > wrote: > >> Let us know how it works. I want to be sure I’m not confusing you >> though. There isn’t a “doc ID field”. The structure of an eff file is >> docid:value >> >> where docid is your <uniqueKey>. What updating numerics does is allow >> you to update a field in a doc that’s identified by <unkqueKey>. That >> field is any name you want as long as it’s defined respecting >> the limitations in that link. >> >> Best, >> Erick >> >>> On Aug 13, 2020, at 6:30 AM, Akshay Murarka <aks...@saavn.com> wrote: >>> >>> Hey Erick, >>> >>> Thanks for the information about the doc ID field. >>> So our external file values are single float value fields and we do use >>> them in functional queries in boost parameter, so based on the definition >>> the above should work. >>> So currently we use solr 5.4.0 but are in the process of upgrading our >>> systems so will try out this change. >>> >>> Regards, >>> Akshay >>> >>> On Mon, Aug 10, 2020 at 10:19 PM Erick Erickson <erickerick...@gmail.com >>> >>> wrote: >>> >>>> Right, but you can use those with function queries. Assuming your eff >>>> entry is a doc ID plus single numeric, I was wondering if you can >>>> accomplish what you need to with function queries... >>>> >>>>> On Aug 10, 2020, at 11:30 AM, raj.yadav <rajkum...@cse.ism.ac.in> >> wrote: >>>>> >>>>> Erick Erickson wrote >>>>>> Ah, ok. That makes sense. I wonder if your use-case would be better >>>>>> served, though, by “in place updates”, see: >>>>>> >>>> >> https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html >>>>>> This has been around in since Solr 6.5… >>>>> >>>>> As per documentation `in place update` is only available for numeric >>>>> docValues (along with few more conditions). And here its external field >>>>> type. >>>>> >>>>> Regards, >>>>> Raj >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html >>>> >>>> >> >>
