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 >> > > >> > >> >
