Hi Uday
So you want to apply a 10x multiplicative boost to documents where a
districtid
is equal to (or one value of) the document's prefdistrictid.
Some alternatives (untested):
* If the field is single-value
DocValue: if(eq(prefdistrictid,$districtid),10,1)
* If the field is multi-value
DocValue: if(query({!v='prefdistrictid:$districtid'}),10,1)
(in the latter you might need to resolve $districtid yourself)
Good luck
Matthias
On Fri, Feb 14, 2025 at 6:10 AM Uday Kumar <uday.p...@indiamart.com.invalid>
wrote:
> 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
> > >
> >
>
