That's right, I want to avoid a complete reindexing process.
But should I create another field with the docValues property or change the
current field directly?
Can I use streaming expressions to update the whole index or should I
select and update using batches?
Thanks,
Mahmoud
On Wed
nteger field on an index with billions of documents and need to do
>facets on this field, unfortunately the field doesn't have the docValues
>property, so the FieldCache will be fired and use much memory.
>
>What is the best way to change the field to be docValues supported?
>
>Regards,
>Mahmoud
Hello,
I've an integer field on an index with billions of documents and need to do
facets on this field, unfortunately the field doesn't have the docValues
property, so the FieldCache will be fired and use much memory.
What is the best way to change the field to be docValues supported
And in the case of both stored=true and docValues=true, Solr 8.x shall be
choosing the optimal approach by itself?
On Wed, Nov 4, 2020 at 9:15 AM Wei wrote:
> Thanks Erick. As indexed is not necessary, and docValues is more
> efficient than stored fields for function queries, so we sh
Thanks Erick. As indexed is not necessary, and docValues is more efficient
than stored fields for function queries, so we shall go with the
following:
3) indexed=false, stored=false, docValues=true.
Is my understanding correct?
Best,
Wei
On Wed, Nov 4, 2020 at 5:24 AM Erick Erickson
question “for doc X, what
is the value of field Y” to compute the score. DocValues are still more
efficient I think, although I
haven’t measured explicitly...
For sorting, faceting and grouping, it’s a much different story. Take sorting.
You have to ask
“for field Y, what’s the value in docX
> On Nov 4, 2020, at 6:43 AM, uyilmaz wrote:
>
> Hi,
>
> I heavily use streaming expressions and facets, or export large amounts of
> data from Solr to Spark to make analyses.
>
> Please correct me if I know wrong:
>
> + requesting a non-docValues field in a
Hi,
I heavily use streaming expressions and facets, or export large amounts of data
from Solr to Spark to make analyses.
Please correct me if I know wrong:
+ requesting a non-docValues field in a response causes whole document to be
decompressed and read from disk
+ streaming expressions and
arser-Thebf_BoostFunctions_Parameter).
It's like boosting a regular field by putting ^2 next to it in a query.
Storing or enabling docValues will unnecesarily consume space/memory.
On Tue, 3 Nov 2020 16:10:50 -0800
Wei wrote:
> Hi,
>
> I have a couple of primitive single value numeric type fiel
Hi,
I have a couple of primitive single value numeric type fields, their
values are used in boosting functions, but not used in sort/facet. or in
returned response. Should I use docValues for them in the schema? I can
think of the following options:
1) indexed=true, stored=true
ysis is too complex to
> do in Solr, we export large query results from Solr to a more capable
> analysis tool.
>
> So I guess all fields need to be docValues="true", because export handler and
> streaming both require fields to have docValues, and even if I won't
all fields need to be docValues="true", because export handler and
streaming both require fields to have docValues, and even if I won't use a
field in queries or facets, it should be in available to read in result set.
Fields that won't be searched or faceted can be (indexe
Hmm. Fields used for faceting will also be used for filtering, which is a kind
of search. Are docValues OK for filtering? I expect they might be slow the
first time, then cached.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Oct 19, 2020, at 11
uyilmaz:
Hmm, that _is_ confusing. And inaccurate.
In this context, it should read something like
The Text field should have indexed="true" docValues=“false" if used for
searching
but not faceting and the String field should have indexed="false"
docValues=“true"
As you've observed, it is indeed possible to facet on fields with
docValues=true, indexed=false; but in almost all cases you should
probably set indexed=true. 1. for distributed facet count refinement,
the "indexed" approach is used to look up counts by value; 2. assuming
you&#
e two
versions of the field: one Text and one String. Make sure both are
indexed="true"."
On Mon, 19 Oct 2020 13:08:00 -0400
Alexandre Rafalovitch wrote:
> I think this is all explained quite well in the Ref Guide:
> https://lucene.apache.org/solr/guide/8_6/docvalues.html
>
I think this is all explained quite well in the Ref Guide:
https://lucene.apache.org/solr/guide/8_6/docvalues.html
DocValues is a different way to index/store values. Faceting is a
primary use case where docValues are better than what 'indexed=true'
gives you.
Regards,
Alex.
On M
Hey all,
>From my little experiments, I see that (if I didn't make a stupid mistake) we
>can facet on fields marked as both indexed and stored being false:
I'm suprised by this, I thought I would need to index it. Can you confirm this?
Regards
--
uyilmaz
l Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > >
> > > On Mon, May 4, 2020 at 10:27 AM Revas wrote:
> > >
> > > > Hi Erick, Thanks for the explanation and advise. With facet queries,
> > does
> > > > doc Values he
blogspot.com/
> >
> >
> > On Mon, May 4, 2020 at 10:27 AM Revas wrote:
> >
> > > Hi Erick, Thanks for the explanation and advise. With facet queries,
> does
> > > doc Values help at all ?
> > >
> > > 1) indexed=true, docValues=true =>
t queries, does
> > doc Values help at all ?
> >
> > 1) indexed=true, docValues=true => all facets
> >
> > 2)
> >
> > - indexed=true , docValues=true => only for subfacets
> >- inexed=true, docValues=false=> facet query
> >
/
On Mon, May 4, 2020 at 10:27 AM Revas wrote:
> Hi Erick, Thanks for the explanation and advise. With facet queries, does
> doc Values help at all ?
>
> 1) indexed=true, docValues=true => all facets
>
> 2)
>
>- indexed=true , docValues=true => only for subfacets
Hi Erick, Thanks for the explanation and advise. With facet queries, does
doc Values help at all ?
1) indexed=true, docValues=true => all facets
2)
- indexed=true , docValues=true => only for subfacets
- inexed=true, docValues=false=> facet query
- docValues=true, inde
DocValues should help when faceting over fields, i.e. facet.field=blah.
I would expect docValues to help with sub facets and, but don’t know
the code well enough to say definitely one way or the other.
The empirical approach would be to set “uninvertible=true” (Solr 7.6) and
turn docValues off
Hi Erick, You are correct, we have only about 1.8M documents so far and
turning on the indexing on the facet fields helped improve the timings of
the facet query a lot which has (sub facets and facet queries). So does
docValues help at all for sub facets and facet query, our tests
revealed further
In a word, “yes”. I also suspect your corpus isn’t very big.
I think the key is the facet queries. Now, I’m talking from
theory rather than diving into the code, but querying on
a docValues=true, indexed=false field is really doing a
search. And searching on a field like that is effectively
We have faceting fields that have been defined as indexed=false,
stored=false and docValues=true
However we use a lot of subfacets using json facets and facet ranges
using facet.queries. We see that after every soft-commit our performance
worsens and performs ideal between commits
how is that
It's hard to predict will it be faster read docValues files or uninvert
field ad-hoc and read them from heap. Only test might judge it.
On Wed, Jan 22, 2020 at 11:08 PM kumar gaurav wrote:
> HI Mikhail
>
> for example :- 6GB index size (Parent-child documents)
> indexing in
HI Mikhail
for example :- 6GB index size (Parent-child documents)
indexing in 12 hours interval .
need to use uniqueBlock for json facet for child faceting .
Should i use docValues="true" for _root_ field ?
Thanks .
regards
Kumar Gaurav
On Thu, Jan 23, 2020 at 1:28 AM Mikhai
It depends from env.
On Wed, Jan 22, 2020 at 9:31 PM kumar gaurav wrote:
> Hi Everyone
>
> Should i use docValues="true" for _root_ field to improve nested child
> json.facet performance ? i am using uniqueBlock() .
>
>
> Thanks in advance .
>
> regards
&
Hi Everyone
Should i use docValues="true" for _root_ field to improve nested child
json.facet performance ? i am using uniqueBlock() .
Thanks in advance .
regards
Kumar Gaurav
GCEasy works fine. GCViewer is something you can have on your local machine,
sometimes if you have very large GC logs uploading them can take quite a
while.
The next step, if you can’t find anything satisfactory is to put a profiler on
the running Solr instance, which will tell you where the time
Hi Erick,
You're right - IO was extraordinarily high. But something odd happened. To
actually build a relation, I tried different heap sizes with default
solrconfig.xml values as you recommended.
1. Increased RAM to 4G, speed 8500k.
2. Decreased to 2G, back to old 65k.
3. Increased back
I doubt GC alone would make nearly that difference. More likely
it’s I/O interacting with MMapDirectory. Lucene uses OS memory
space for much of its index, i.e. the RAM left over
after that used for the running Solr process (and any other
processes of course). See:
https://blog.thetaphi.de/2012/07
Just to update, I kept the defaults. The indexing got only a little boost
though I have decided to continue with the defaults and do incremental
experiments only. To my surprise, our development server had only 12GB RAM,
of which 8G was allocated to Java. Because I could not increase the RAM, I
tri
Note that that article is from 2011. That was in the Solr 3x days when many,
many, many things were different. There was no SolrCloud for instance. Plus
Tom’s problem space is indexing _books_. Whole, complete, books. Which is,
actually, not “normal” indexing at all as most Solr indexes are much
Hi Erick,
I have reverted back to original values and yes, I did see improvement. I
will collect more stats. *Thank you for helping. :)*
Also, here is the reference article that I had referred for changing
values:
https://www.hathitrust.org/blogs/large-scale-search/forty-days-and-forty-nights-re-
Hey Erick,
We have just upgraded to 8.3 before starting the indexing. We were on 6.6
before that.
Thank you for your continued support and resources. Again, I have already
taken your suggestion to start afresh and that's what I'm going to do.
Don't get me wrong but I have been just asking doubts.
Nothing implicitly handles optimization, you must continue to do that
externally.
Until you get to the bottom of your indexing slowdown, I wouldn’t bother
with it at all, trying to do all these things at once is what lead to your
problem in the first place, please change one thing at a time. You s
Hi Erick,
I believed optimizing explicitly merges segments and that's why I was
expecting it to give performance boost. I know that optimizations should
not be done very frequently. For a full indexing, optimizations occurred 30
times between batches. I take your suggestion to undo all the changes
> I think I should have also done optimize between batches, no?
No, no, no, no. Absolutely not. Never. Never, never, never between batches.
I don’t recommend optimizing at _all_ unless there are demonstrable
improvements.
Please don’t take this the wrong way, the whole merge process is really
h
Hey Erick,
This is a huge red flag to me: "(but I could only test for the first few
> thousand documents”.
Yup, that's probably where the culprit lies. I could only test for the
starting batch because I had to wait for a day to actually compare. I
tweaked the merge values and kept whatever gave
This is a huge red flag to me: "(but I could only test for the first few
thousand documents”
You’re probably right that that would speed things up, but pretty soon when
you’re indexing
your entire corpus there are lots of other considerations.
The indexing rate you’re seeing is abysmal unless t
dates fetch the matching document by
> > uniqueKey and then does the normal index using the information in the
> > fetched document. Is this actually taking time? As the number of
> documents
> > increases, Solr might be taking time to fetch the stored document.
> >
ocument. Is this actually taking time? As the number of documents
> increases, Solr might be taking time to fetch the stored document.
>
> But shouldn't the fetch by uniqueKey take O(1) time? If this really impacts
> the fetch, can we use docValues for the field id (uniqueKe
might be taking time to fetch the stored document.
But shouldn't the fetch by uniqueKey take O(1) time? If this really impacts
the fetch, can we use docValues for the field id (uniqueKey)? Our field is
of type string.
I'm pasting my con
update request processor
> chain and have all the logic in Solr. Here is blog post explaining how it
> could work:
> https://www.od-bits.com/2018/02/solr-docvalues-on-analysed-field.html <
> https://www.od-bits.com/2018/02/solr-docvalues-on-analysed-field.html>
>
> HTH,
&g
Hi Antony,
Like Erick explained, you still have to preprocess your field in order to be
able to use doc values. What you can do is use update request processor chain
and have all the logic in Solr. Here is blog post explaining how it could work:
https://www.od-bits.com/2018/02/solr-docvalues-on
So “lowercase” is, indeed, a solr.TextField, which is ineligible for docValues.
Given that definition, the difference will be that a “string” type is totally
un-analyzed, so the values that go into the index and the query itself will be
case-sensitive. You’ll have to pre-process both to do the
our use case.
> 2> we don’t know what the field type “lowercase” does. It’s composed of an
> analysis chain that you may have changed. And whatever config you are using
> may have changed with different releases of Solr.
>
> Grouping is generally done on a docValues-eligible field typ
ferent releases of Solr.
Grouping is generally done on a docValues-eligible field type. AFAIK,
“lowercase” is a solr-text based field so is ineligible for docValues. I’ve got
to guess here, but I’d suggest you start with a fieldType of “string”, and
enable docValues on it.
Best,
Erick
> On No
>
> Hi Shawn,
>
I will try that solution. Also I had to mention that the queries that fail
with this error has the "group.field":"lowercase". Should I change the
field type?
Thanks,
Antony
java.lang.IllegalStateException: unexpected
docvalues type SORTED_SET for field 'lowercase' (expected=SORTED). Re-index
with correct docvalues type.
This error means that part of the index was created with one definition
for the field in question, then the schema was changed in an
incompatibl
docvalues type SORTED_SET for field 'lowercase' (expected=SORTED). Re-index
with correct docvalues type.
at org.apache.lucene.index.DocValues.checkField(DocValues.java:340)
at org.apache.lucene.index.DocValues.getSorted(DocValues.java:392)
ordered list of terms, each term has the list of documents it appears in.
DocValues is the exact opposite. It answers “For doc X, what is the value of
field Y?”. When _searching_ on a DV only field, think “table scan” in DB terms.
Pick a field with high cardinality. Worst-case, every doc has a unique
On 9/14/2019 4:29 PM, Mikhail Khludnev wrote:
Shawn, would you mind to provide some numbers?
I'm experimenting with lucene 8.0.0.
I have 100 shard index of 100M docs with 2000 docVals only updateable
fields. Searching for such field turns to be blazingly fast
$ curl 'localhost:39200/books/_search
ot; : {
"subscription_0x1" : {
"type" : "integer",
"boost" : 1.0,
"index" : false,
"store" : false,
"doc_values" : true,
"term_vector" : &quo
On 9/10/2019 7:15 AM, Doss wrote:
4 to 5 million documents.
For an NTR index, we need a field to be updated very frequently and filter
results based on it. Will In-Place updates help us?
Although you CAN search on docValues-only fields, the performance is
terrible. So the answer I have
ones.
These are updateable inplace.
On Tue, Sep 10, 2019 at 4:15 PM Doss wrote:
> Hi,
>
> 4 to 5 million documents.
>
> For an NTR index, we need a field to be updated very frequently and filter
> results based on it. Will In-Place updates help us?
>
> docValues="true
Hi,
4 to 5 million documents.
For an NTR index, we need a field to be updated very frequently and filter
results based on it. Will In-Place updates help us?
Thanks,
Doss.
DocValues are irrelevant for scoring. Here’s the way I think of it.
When querying (and thus scoring), you have a term X. I need to know
> what docs does it appear in?
> how many docs does it appear in?
> how often does the term appear in the entire corpus?
These are questions the inver
Hi everybody,
I can't find concrete evidence whether docValues are indeed useful for
filter queries. One example of a field:
This field will have a value between 0-1 The only usecase for this
field is to filter on a range / subset of values. There will be no scoring
/ querying on
; > my (1)
> > > dog (1)
> > > has (1)
> > > fleas (1)
> > >
> > > But for SortableText will be:
> > >
> > > my dog has fleas (1)
> > >
> > > Consider doc1 with “my dog has fleas” and doc2 with “my cat has fleas”.
>
t; > my (1)
> > dog (1)
> > has (1)
> > fleas (1)
> >
> > But for SortableText will be:
> >
> > my dog has fleas (1)
> >
> > Consider doc1 with “my dog has fleas” and doc2 with “my cat has fleas”.
> > doc1 was indexed before switching to
t; my cat has fleas (1)
>
> But you can’t get that output. There are three cases:
>
> 1> Lucene treats all documents as SortableText, faceting on the docValues
> parts. No facets on doc1
>
> my cat has fleas (1)
>
> 2> Lucene treats all documents as tokenized, faceting on e
after. Presumably the
output you want is:
my dog has fleas (1)
my cat has fleas (1)
But you can’t get that output. There are three cases:
1> Lucene treats all documents as SortableText, faceting on the docValues
parts. No facets on doc1
my cat has fleas (1)
2> Lucene treats all d
at can Lucene do? Consider:
>
> Faceting on a text (not sortable) means that each individual token in the
> index is uninverted on the Java heap and the facets are computed for each
> individual term.
>
> Faceting on a SortableText field just has a single term per document, and
.
Faceting on a SortableText field just has a single term per document, and that
in the docValues structures as opposed to the inverted index.
Now you change the value and start indexing. At some point a segment containing
no docValues is merged with a segment containing docValues for the field. The
Hi there,
We recently changed a field from TextField + no docValues to
SortableTextField which has docValues enabled by default. Once I did this I
do not see any facet values for the field. I know that once all the docs
are re-indexed facets should work again, however can someone clarify the
maybe quite late to the party but for the benefit of future readers,
experimentation with facet.range.method might be helpful (for solr versions
6 and above) as it allows us to use docValues as well for range faceting
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
"Re-index with correct docvalues”. I.e. define weight to have docValues=true in
your schema. WARNING: you have to totally get rid of your current data, I’d
recommend starting with a new collection.
> On Apr 10, 2019, at 12:21 AM, Alex Broitman
> wrote:
>
> We got the So
t; gid="21" group="34" pcid="6"
ecid="174"}202.2+(Dashboard Dashboard*)edismaxDashboardname nls_NAME___en-ustrueproduct(sum(1,product(norm(acl_i),termfreq(acl_i,5164077))),if(exists(weight),weight,1))sysid1trueunexpected docvalues type NUMERIC for field &
d not for sorting, faceting or highlighting -
> should I use docValues=true or stored=true to enable atomic updates? Or even
> both? I understand that either docValues or stored fields are needed for
> atomic updates but which of the two would perform better / consume less
> resources i
Hi,
I have a question on schema design: If a single-valued StrField is just
used for filtering results by exact value (indexed=true) and its value
isn't needed in the search result and not for sorting, faceting or
highlighting - should I use docValues=true or stored=true to enable
a
Looks like: https://issues.apache.org/jira/browse/SOLR-11728
> On Apr 3, 2019, at 1:09 AM, JiaJun Zhu wrote:
>
> Hello,
>
>
> I got an "Unexpected docvalues type SORTED_NUMERIC" exception when I perform
> group facet on an IntPointField. Debugging into the so
Hello,
I got an "Unexpected docvalues type SORTED_NUMERIC" exception when I perform
group facet on an IntPointField. Debugging into the source code, the cause is
that internally the docvalue type for PointField is "NUMERIC" (single value) or
"SORTED_NUMERIC&
It make sense to have docValues=true for _root_ for uniqueBlock()
On Thu, Nov 22, 2018 at 6:44 PM Vincenzo D'Amore wrote:
> Hi guys, this is an interesting thread.
>
> Looking at schema.xml I found having uniqueKey (type="string") configured
> as docValues="tru
/export needs all fields to be docValues. If you are going to export, including
the id seems like a good idea.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Nov 22, 2018, at 6:51 PM, Erick Erickson wrote:
>
> I doubt it mattes. The o
I doubt it mattes. The only point for docValues is to speed up
situations where you want to answer the question "for docX, what is
the value of fieldY"? Unless you're doing something interesting with
the_route_ field, it's only used to, well, route documents at index
time. B
Hi guys, this is an interesting thread.
Looking at schema.xml I found having uniqueKey (type="string") configured
as docValues="true" but, I also found that _root_ is
configured docValues="false"
Is there any drawbacks in having _root_ with docValues="false&qu
,
Erick
On Wed, Nov 21, 2018 at 12:04 PM Walter Underwood wrote:
>
> Is it a good idea to store the uniqueKey as docValues? A great idea? A maybe
> or maybe not idea?
>
> It looks like it will speed up export and streaming. Otherwise, I can’t find
> anything the docs pro or con.
&
Is it a good idea to store the uniqueKey as docValues? A great idea? A maybe or
maybe not idea?
It looks like it will speed up export and streaming. Otherwise, I can’t find
anything the docs pro or con.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
On Tue, 2018-11-20 at 21:17 -0700, Shawn Heisey wrote:
> Maybe the error condition should be related to a new schema
> property, something like allowQueryOnDocValues. This would default
> to true with current schema versions and false in the next schema
> version, which I think is 1.7. Then a use
On 11/20/2018 8:18 PM, Rahul Goswami wrote:
Erick and Toke,
Thank you for the replies. I am surprised there already isn’t a JIRA for
this. In my opinion, this should be an error condition on search or
alternatively should simply be giving zero results. That would be a defined
behavior as opposed
particularly
functional for any industry size load anyway.
Thanks,
Rahul
On Tue, Nov 20, 2018 at 3:37 AM Toke Eskildsen wrote:
> On Mon, 2018-11-19 at 22:19 -0500, Rahul Goswami wrote:
> > I am using SolrCloud 7.2.1. My understanding is that setting
> > docvalues=true would optimize fac
On Mon, 2018-11-19 at 22:19 -0500, Rahul Goswami wrote:
> I am using SolrCloud 7.2.1. My understanding is that setting
> docvalues=true would optimize faceting, grouping and sorting; but for
> a field to be searchable it needs to be indexed=true.
Erick explained the search thing, so
I've noticed this too, but I think it's more a side effect than
something usable for the reasons you outlined. Searching a docValues
field is akin to a "table scan", the uninverted structure is totally
unsuited for searching. It works, but as you've found out it's
I am using SolrCloud 7.2.1. My understanding is that setting docvalues=true
would optimize faceting, grouping and sorting; but for a field to be
searchable it needs to be indexed=true. However I was dumbfounded today
when I executed a successful search on a field with below configuration:
However
gt;>
> >> "Does this still hold if whole index is loaded into memory?"
> >> The decompression part yes, the disk seek part no. And it's also
> >> sensitive to whether the documentCache already has the document.
> >>
> >> I'd also make u
t;
>> "Does this still hold if whole index is loaded into memory?"
>> The decompression part yes, the disk seek part no. And it's also
>> sensitive to whether the documentCache already has the document.
>>
>> I'd also make uniqueKey ant the _version
memory?"
> > The decompression part yes, the disk seek part no. And it's also
> > sensitive to whether the documentCache already has the document.
> >
> > I'd also make uniqueKey ant the _version_ fields docValues.
> >
> > Best,
> > Erick
&
h that JIRA, so only
> in 7x.
>
> "Does this still hold if whole index is loaded into memory?"
> The decompression part yes, the disk seek part no. And it's also
> sensitive to whether the documentCache already has the document.
>
> I'd also make uniqueKey
I'd also make uniqueKey ant the _version_ fields docValues.
Best,
Erick
On Tue, Nov 6, 2018 at 10:44 AM Wei wrote:
>
> Thanks Yasufumi and Erick.
>
> ---. 2. "it depends". Solr will try to do the most efficient thing
> possible. If _all_ the fields are docValues
Thanks Yasufumi and Erick.
---. 2. "it depends". Solr will try to do the most efficient thing
possible. If _all_ the fields are docValues, it will return the stored
values from the docValues structure.
I find this jira: https://issues.apache.org/jira/browse/SOLR-8344Does
this
2. "it depends". Solr will try to do the most efficient thing
possible. If _all_ the fields are docValues, it will return the stored
values from the docValues structure. This prevents a disk seek and
decompress cycle.
However, if even one field is docValues=false Solr will by default
Hi,
> 1. For schema version 1.6, useDocValuesAsStored=true is default, so there
> is no need to explicitly set it in schema.xml?
Yes.
> 2. With useDocValuesAsStored=true and the following definition, will Solr
> retrieve id from docValues instead of stored field?
No.
AFAIK, if you
Hi,
I have a few questions about using the useDocValuesAsStored option to
retrieve field from docValues:
1. For schema version 1.6, useDocValuesAsStored=true is default, so there
is no need to explicitly set it in schema.xml?
2. With useDocValuesAsStored=true and the following definition, will
f there isn't one already
>
> On Fri, Aug 10, 2018, 19:49 Karthik Ramachandran <
> kramachand...@commvault.com> wrote:
>
> > We are using Solr 7.2.1, highlighting is not working with docValues only
> > String field.
> >
> > Should I open a JIRA
re using Solr 7.2.1, highlighting is not working with docValues only
> String field.
>
> Should I open a JIRA for this?
>
> Schema:
>
> id
>
>required="true"/>
>stored="true"/>
>stored="false"/>
>
>
>
&g
We are using Solr 7.2.1, highlighting is not working with docValues only String
field.
Should I open a JIRA for this?
Schema:
id
Data:
[{"id":1,"name":"Testing line 1"},{"id":2,"name":"Testing line
2"},{"i
1 - 100 of 535 matches
Mail list logo
