Yes but "the _version_ field is also a non-indexed, non-stored single valued docValues field;" <- is that a problem?
My schema has this: <!-- to use updateLog: _version_field must exist in schema, using indexed="true" stored="true" and multiValued="false" --> <field name="_version_" type="long" indexed="true" stored="true"/> I don't know if I use the updateLog or not. How can I find out? I think that would work for me as I could just make a dynamic fild like: <dynamicField name="*_atomici" type="int" indexed="false" stored="false" multiValued="false" required="false" docValues="true" /> --- Yes it is just for functions, sorting, and boosting On Mon, Sep 14, 2020 at 4:51 PM Erick Erickson <erickerick...@gmail.com> wrote: > > Have you seen “In-place updates”? > > See: > https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html > > Then use the field as part of a function query. Since it’s non-indexed, you > won’t be searching on it. That said, you can do a lot with function queries > to satisfy use-cases. > > Best. > Erick > > > On Sep 14, 2020, at 3:12 PM, matthew sporleder <msporle...@gmail.com> wrote: > > > > I have hit a bit of a cross-road with our usage of solr where I want > > to include some slightly dynamic data. > > > > I want to ask solr to find things like "text query" but only if they > > meet some specific criteria. When I have all of those criteria > > indexed, everything works great. (text contains "apples", in_season=1 > > ,sort by latest) > > > > Now I would like to add a criteria which changes every day - > > popularity of a document, specifically. This appeared to be *the* > > canonical use case for external field files but I have 50M documents > > (and growing) so a *text* file doesn't fit the bill. > > > > I also looked at using a !join but the limitations of !join, as I > > understand them, appear to mean I can't use it for my use case? aka I > > can't actually use the data from my traffic-stats core to sort/filter > > "text contains" "apples", in_season=1, sort by most traffic, sort by > > latest > > > > The last option appears to be updating all of my documents every > > single day, possibly using atomic/partial updates, but even those have > > a growing list of gotchas: losing stored=false documents is a big one, > > caveats I don't quite understand related to copyFields, changes to the > > _version_ field (the _version_ field is also a non-indexed, non-stored > > single valued docValues field;), etc > > > > Where else can I look? The last time we attempted something like this > > we ended up rebuilding the index from scratch each day and shuffling > > it out, which was really pretty nasty. > > > > Thanks, > > Matt >