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 >
