Op za 20 mei 2023 om 21:18 schreef Shawn Heisey :
> Agreed. There are many situations outside of version upgrades where
> rebuilding the index from scratch is an absolute requirement. It is
> something all Solr users need to be able to do at ANY time. I used to
> maintain an index where a full
On 5/20/23 12:14, Dave wrote:
I never trust a solr upgrade path with an index from one major version to
another. It has to be completely recreated in my opinion with the updated
schema as sometimes there may be major changes, even though it’s said you can
go two versions up with the same inde
I never trust a solr upgrade path with an index from one major version to
another. It has to be completely recreated in my opinion with the updated
schema as sometimes there may be major changes, even though it’s said you can
go two versions up with the same index using the upgrade path. I’ve
On 5/19/23 15:39, Christopher Schultz wrote:
Please confirm the following:
1. Solr index is created with Solr 7.something
2. Solr 8.x is deployed and all is well
3. Index is re-built by replacing 100% of documents in the index
4. Solr 9.x is deployed and all is well
Is that correct, especially
Shawn,
On 5/18/23 14:35, Shawn Heisey wrote:
On 5/18/23 10:27, Christopher Schultz wrote:
I didn't know there were multiple SolrJ implementations. I'm using the
client library directly from the Solr project with a version number of
7.7.3. It looks like I have been running against an 8.1.1 serv
On 5/18/23 10:27, Christopher Schultz wrote:
I didn't know there were multiple SolrJ implementations. I'm using the
client library directly from the Solr project with a version number of
7.7.3. It looks like I have been running against an 8.1.1 server in my
development environment while we have
Shawn,
On 5/17/23 21:45, Shawn Heisey wrote:
On 5/17/23 11:40, Christopher Schultz wrote:
Thanks for your replies and I apologize for the noise. I'll pick this
thread back up if for some reason I am able to reproduce the issue.
I can't tell you how many times I have done this. Ask for help,
On 5/17/23 11:40, Christopher Schultz wrote:
Thanks for your replies and I apologize for the noise. I'll pick this
thread back up if for some reason I am able to reproduce the issue.
I can't tell you how many times I have done this. Ask for help, and
while working diligently to document the p
Shawn and Alexandre,
On 5/17/23 13:12, Shawn Heisey wrote:
On 5/17/23 10:01, Christopher Schultz wrote:
The "all" field contains copies of the other fields values for each
record I've studied except for "identifier".
I have re-indexed the whole document set and the "all" field still
does not
On 5/17/23 10:01, Christopher Schultz wrote:
The "all" field contains copies of the other fields values for each
record I've studied except for "identifier".
I have re-indexed the whole document set and the "all" field still does
not contain the values I can see (in the search results) for "id
Is your "all" field set to store=true? It should not be, but that means it
would not show up in search results but still will be indexed and
searchable against.
You could look at tokenized content or temporarily try setting fields to
stored=true and reindexing.
On Wed., May 17, 2023, 12:01 p.m. C
All,
I have a Solr 7.7.3 server with a pretty simply index including a
copy-field. I have confirmed that the actually-loaded index contains
these (among other) fields:
- identifier, type=text_general, multivalued=true ("copied to 'all'")
- all, type-text_general, multivalued=true ("copied fro
12 matches
Mail list logo
