Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rebase on vanilla Solr 9.3 #9826

Merged
merged 4 commits into from Aug 24, 2023
Merged

Rebase on vanilla Solr 9.3 #9826

merged 4 commits into from Aug 24, 2023

Conversation

poikilotherm
Copy link
Contributor

@poikilotherm poikilotherm commented Aug 24, 2023

Replacing with files compiled from using the vanilla 9.3 config / schema and applying our tweaks.

This is related to PR #9787 as this PR targets the base branch of that one.

Instead of keeping the XML file originating from Solr 7 around,
let's put our customisations in the vanilla config.

The indentation changed, so this looks like an "everything changed"
thing.

Aside from that, we are doing three changes:
1. Enable ClassicIndexSchemaFactory
2. Disable schemaless via "update.autoCreateFields:false"
3. Tweak our searches in /select request handler
- No longer use Trie*Fields, switch all to point fields (Trie has been
  deprecated since 9)
- Add some new field types added since Solr 9 came out
@pdurbin
Copy link
Member

pdurbin commented Aug 24, 2023

I just did a couple "diffs" of vanilla Solr 9.3.0 vs the versions in this pull request.

The diff for solrconfig.xml makes perfect sense to me. Only a few lines changed: solrconfigdiff.txt 🚀

I'm find it hard to understand why the diff is so much bigger for schema.xml: schemadiff.txt . It's much harder to reason about. 🤔

It makes me wonder if a script was used to create schema.xml? If so, where is the script? How would I reproduce these results?

@poikilotherm I love the approach but let's discuss! Thanks for the PR!

@pdurbin pdurbin mentioned this pull request Aug 24, 2023
Copy link
Member

@pdurbin pdurbin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a comment for @qqmyers

@@ -163,7 +156,7 @@

<field name="publicationStatus" type="string" stored="true" indexed="true" multiValued="true"/>
<field name="externalStatus" type="string" stored="true" indexed="true" multiValued="false"/>
<field name="embargoEndDate" type="long" stored="true" indexed="true" multiValued="false"/>
<field name="embargoEndDate" type="plong" stored="true" indexed="true" multiValued="false"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qqmyers do you remember why you picked long for embargoEndDate when releasedate uses int?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. I see in the IndexServiceBean that the embargo date is turned into a long via toEpochDay() where the release date is indexed directly as a timestamp, but I'm not sure why that is.

@pdurbin pdurbin marked this pull request as ready for review August 24, 2023 16:30
@pdurbin pdurbin merged commit 31ce7ac into 9260-solr930 Aug 24, 2023
5 of 7 checks passed
@pdurbin pdurbin added this to the 6.0 milestone Sep 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants