On 10/17/2020 6:23 AM, Vinay Rajput wrote:
That said, one more time I want to come back to the same question: why
solr/lucene can not handle this when we are updating all the documents?
Let's take a couple of examples :-
*Ex 1:*
Let's say I have only 10 documents in my index and all of them are
Did you read the long explanation in this thread already about
segment merging? If so, can you ask specific questions about
the information in those?
Best,
Erick
> On Oct 17, 2020, at 8:23 AM, Vinay Rajput wrote:
>
> Sorry to jump into this discussion. I also get confused whenever I see this
>
Because Solr is not updating documents. Solr is adding to indexes
of fields. You cannot add a TextField document to a StringField index.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Oct 17, 2020, at 5:23 AM, Vinay Rajput wrote:
>
> Sorry to jump
Sorry to jump into this discussion. I also get confused whenever I see this
strange Solr/Lucene behaviour. Probably, As @Erick said in his last year
talk, this is how it has been designed to avoid many problems that are
hard/impossible to solve.
That said, one more time I want to come back to the
On 10/16/2020 2:36 PM, David Hastings wrote:
sorry, i was thinking just using the
*:*
method for clearing the index would leave them still
In theory, if you delete all documents at the Solr level, Lucene will
delete all the segment files on the next commit, because they are empty.
I have
In addition, what happens at query time when documents have
been index under a varying field type? Well, it doesn’t work well.
The full set of steps for uninterrupted searching is:
1. Add the new text field.
2. Reindex to populate that.
3. Switch querying to use the new text field.
4. Change the
sorry, i was thinking just using the
*:*
method for clearing the index would leave them still
On Fri, Oct 16, 2020 at 4:28 PM Erick Erickson
wrote:
> Not sure what you’re asking here. re-indexing, as I was
> using the term, means completely removing the index and
> starting over. Or indexing to
Not sure what you’re asking here. re-indexing, as I was
using the term, means completely removing the index and
starting over. Or indexing to a new collection. At any
rate, starting from a state where there are _no_ segments.
I’m guessing you’re still thinking that re-indexing without
doing the
Gotcha, thanks for the explanation. another small question if you
dont mind, when deleting docs they arent actually removed, just tagged as
deleted, and the old field/field type is still in the index until
merged/optimized as well, wouldnt that cause almost the same conflicts
until then?
On Fri,
Doesn’t re-indexing a document just delete/replace….
It’s complicated. For the individual document, yes. The problem
comes because the field is inconsistent _between_ documents, and
segment merging blows things up.
Consider. I have segment1 with documents indexed with the old
schema (String in
"If you want to
keep the same field name, you need to delete all of the
documents in the index, change the schema, and reindex."
actually doesnt re-indexing a document just delete/replace anyways assuming
the same id?
On Fri, Oct 16, 2020 at 3:07 PM Alexandre Rafalovitch
wrote:
> Just as a
Just as a side note,
> indexed="true"
If you are storing 32K message, you probably are not searching it as a
whole string. So, don't index it. You may also want to mark the field
as 'large' (and lazy):
No. The data is already indexed as a StringField.
You need to make a new field and reindex. If you want to
keep the same field name, you need to delete all of the
documents in the index, change the schema, and reindex.
wunder
Walter Underwood
wun...@wunderwood.org
I am using solr 8.2
Can I change the schema fieldtype from string to solr.TextField
without indexing?
The reason is that string has only 32K char limit where as I am looking to
store more than 32K now.
The contents on this field doesn't require any analysis or tokenized but I
need this
14 matches
Mail list logo
