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
>

Reply via email to