Hi Matthias, I'm curious what use case(s) you have in mind for knowing how often a specific numerical value appears in a document's (dv) field?
We use this in combination with if() for boosting in our queries *Sample:* boost=if(termfreq(prefdistrictid, $districtid),10,1)&districtid=1234 *Thanks & Regards,* *Uday Kumar* On Thu, Feb 13, 2025 at 7:03 PM Matthias Krüger < mkrue...@opensourceconnections.com> wrote: > Hi Uday, > > I'm curious what use case(s) you have in mind for knowing how often a > specific numerical value appears in a document's (dv) field? > > Matt > > On Thu, Feb 13, 2025 at 2:09 PM Mikhail Khludnev <m...@apache.org> wrote: > > > Hi > > These term* functions are for indexed fields (inverted index) per se. > > I'm wondering if it's ever possible to implement them for points or dv > > columns. > > > > On Thu, Feb 13, 2025 at 1:51 PM Uday Kumar <uday.p...@indiamart.com > > .invalid> > > wrote: > > > > > Hi, > > > As a part of In-Place updates POC, I am testing schema and > functionality > > by > > > running queries using different function queries > > > > > > *sample schema:* > > > <fieldType name="int" class="solr.IntPointField" omitNorms="true" > > > positionIncrementGap="0" docValues="true"/> > > > <field name="InPlaceField" type="int" indexed="false" stored="false" > > > required="false" omitNorms="true" multiValued="false"/> > > > > > > *I have found the termfreq() function is not working on pointFields. > i.e > > > giving "0" always* > > > > > > *Sample Query:* > > > q.alt=*:*&fl=testValue:*termfreq(InPlaceField,699)* > > > > > > Other functions which are not working: > > > sumtotaltermfreq(), tf(), totaltermfreq() etc > > > > > > I have found this link ( > https://issues.apache.org/jira/browse/SOLR-13757 > > ), > > > where it mentioned it does not support > > > > > > Do we have any alternative for the same without impacting performance > of > > > solr? > > > > > > *Thanks & Regards,* > > > *Uday Kumar* > > > > > > > > > On Wed, Feb 12, 2025 at 6:42 AM Uday Kumar <uday.p...@indiamart.com> > > > wrote: > > > > > > > Okay, thanks for confirming > > > > > > > > On Tue, Feb 11, 2025, 18:47 Matthias Krüger < > > > > mkrue...@opensourceconnections.com> wrote: > > > > > > > >> Yes. The only advantage of "atomic update" is that you don't need to > > > send > > > >> all fields in an update. Still all fields > > > >> will get re-analyzed (the ones that were not part of the request are > > > >> restored from their stored field value) > > > >> and reindexed. It is more of a convenience feature than a > performance > > > >> improvement. > > > >> > > > >> In-place updates happen on DocValues only. They are just overwritten > > > with > > > >> their new value without affecting > > > >> the rest of the document. An ecom use case would be volatile numeric > > > >> values > > > >> such as stock levels or pricing information. > > > >> You can use them in filters, facets and get them as part of the > > document > > > >> response. > > > >> > > > >> > > > >> On Tue, Feb 11, 2025 at 1:26 PM Uday Kumar <uday.p...@indiamart.com > > > >> .invalid> > > > >> wrote: > > > >> > > > >> > Okay got it! > > > >> > > > > >> > So, to summarize > > > >> > > > > >> > when a field needs to be updated, > > > >> > *by traditional update:* > > > >> > all fields are changed and entire document is reindexed/replaced > > > >> > > > > >> > *by atomic update:* > > > >> > specific fields are changed and document is reindexed > > > >> > > > > >> > *by in-place update:* > > > >> > Only specific fields are changed and those specific fields are > > > reindexed > > > >> > > > > >> > Hope, my understanding is right...? > > > >> > > > > >> > *Thanks & Regards,* > > > >> > *Uday Kumar* > > > >> > *Product Search Tech* > > > >> > > > > >> > > > > >> > On Tue, Feb 11, 2025 at 5:02 PM Mikhail Khludnev <m...@apache.org > > > > > >> wrote: > > > >> > > > > >> > > Hello please find the comments inline > > > >> > > > > > >> > > On Tue, Feb 11, 2025 at 12:43 PM Uday Kumar < > > > uday.p...@indiamart.com > > > >> > > .invalid> > > > >> > > wrote: > > > >> > > > > > >> > > > Hi all, > > > >> > > > *In Place updates:* > > > >> > > > Works with fields which are non-indexed and non-stored > > > >> > > > > > >> > > > > > >> > > docValue-based numeric fields. > > > >> > > > > > >> > > > > > >> > > > 1. This meant we cannot query on this field and cannot display > > the > > > >> > value > > > >> > > of > > > >> > > > the field. > > > >> > > > > > > >> > > Such fields at least might be queried with range query parser, > but > > > >> iirc > > > >> > > (but might be wrong), there's a handling in regular term:query > > > syntax > > > >> for > > > >> > > such fields. > > > >> > > > > > >> > > > > > >> > > > 2. Found one contradictory statement in *in-place* updates > > section > > > >> > > > Link > > > >> > > > < > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > https://solr.apache.org/guide/solr/latest/indexing-guide/partial-document-updates.html#in-place-updates > > > >> > > > > > > > >> > > > "In regular > > > >> > > > > > >> > > **atomic updates,** > > > >> > > > > > >> > > > the entire document is reindexed internally > > > >> > > > during the application of the update. > > > >> > > > > > >> > > > > > >> > > > > > >> > > > However, in this approach, > > > >> > > > > > >> > > (implying in-place udt) > > > >> > > > > > >> > > > only the > > > >> > > > fields to be updated are affected and the rest of the > documents > > > are > > > >> not > > > >> > > > reindexed internally" > > > >> > > > > > > >> > > > Isn't this contradictory with the atomic updates concept? > > > >> > > > > > > >> > > Yes. It is clear to me. Don't see a contraction. > > > >> > > > > > >> > > Please share your experiment results afterwards. > > > >> > > > > > >> > > > > > >> > > -- > > > >> > > Sincerely yours > > > >> > > Mikhail Khludnev > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > -- > > Sincerely yours > > Mikhail Khludnev > > >
