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

Use the smallest version rather than the default version #11475

Merged
merged 1 commit into from Jun 3, 2015

Conversation

s1monw
Copy link
Contributor

@s1monw s1monw commented Jun 3, 2015

The minimum version comparison was always using the default version
sicne the comparison was flipped.

Closes #11474

@s1monw s1monw added the review label Jun 3, 2015
@s1monw
Copy link
Contributor Author

s1monw commented Jun 3, 2015

@rjernst @imotov can you review?

@@ -59,5 +62,6 @@ public void testUpgradeMixed_0_20_6_and_0_90_6() throws Exception {

// We succeeded in upgrading only the ancient segments but leaving the "merely old" ones untouched:
assertTrue(UpgradeTest.hasOldButNotAncientSegments(client(), indexName));
assertEquals(Version.CURRENT.luceneVersion.toString(), client().admin().indices().prepareGetSettings(indexName).get().getSetting(indexName, IndexMetaData.SETTING_VERSION_MINIMUM_COMPATIBLE));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm confused about this assert. especially given the comments above it. If this minimum version is a lucene version, should it not be the oldest lucene version? In this case the ancient segments will be upgraded, but the "merely old" ones will still be there, so I can't see it being CURRENT.

@rmuir
Copy link
Contributor

rmuir commented Jun 3, 2015

I added some questions. One bigger question is: I don't like the hoops we are jumping through here. I also don't like the hoops lucene jumps through just to deliver the correct exception. Maybe lucene should store the minimum version inside the segments_N when we commit? If its an empty commit, its still populated with that version. This might simplify lucene itself on reading commits and make stuff like this easier for everyone.

@s1monw
Copy link
Contributor Author

s1monw commented Jun 3, 2015

@rmuir I mixed something up you are right the test assertion didn't make sense

@rjernst
Copy link
Member

rjernst commented Jun 3, 2015

+1

@rjernst
Copy link
Member

rjernst commented Jun 3, 2015

Also +1 to storing min version in segments_N @rmuir

luceneVersion = segment.getVersion();
}
}
return luceneVersion;
return luceneVersion == null ? Version.indexCreated(indexSettings).luceneVersion : luceneVersion;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

OK but this indexCreated is an immutable thing in ES right? So this means a user can never upgrade an empty index?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

if there are no docs in the index it won't do anything here yes! in this case we should make this method more low level - I will fix that too

@mikemccand
Copy link
Contributor

+1 to have Lucene track this in segments_N

@s1monw
Copy link
Contributor Author

s1monw commented Jun 3, 2015

I added more are asserts, I think the empty index is a different issue and should be solved elsewhere it's pretty tricky to get the version the segmetns_N file was written. I think we are good to go

@imotov
Copy link
Contributor

imotov commented Jun 3, 2015

If this is an empty index, maybe we can just return org.apache.lucene.util.Version.LUCENE_4_0_0 in 1.x and org.apache.lucene.util.Version.LUCENE_5_0_0 in master since it doesn't have any segments anyway, so it's compatible with that, and if we will index any records afterwards, this is the version that we are going to get. Otherwise LGTM.

@s1monw
Copy link
Contributor Author

s1monw commented Jun 3, 2015

If this is an empty index, maybe we can just return org.apache.lucene.util.Version.LUCENE_4_0_0 in 1.x and org.apache.lucene.util.Version.LUCENE_5_0_0 in master since it doesn't have any segments anyway, so it's compatible with that, and if we will index any records afterwards, this is the version that we are going to get. Otherwise LGTM.

the problem is that if we try to open an empty index with a version taht doesn't support this segments_N format we get an exception we can't recover from so somehow we need to be able to upgrade it

@rmuir
Copy link
Contributor

rmuir commented Jun 3, 2015

+1 Lets spin off the empty index separately into another PR? We can leave a TODO for that. I still feel strongly it should be fixed, but this moves things forward.

The minimum version comparison was always using the default version
sicne the comparison was flipped.

Closes elastic#11474
@s1monw s1monw merged commit 8c740eb into elastic:1.x Jun 3, 2015
@s1monw s1monw removed the review label Jun 3, 2015
@imotov
Copy link
Contributor

imotov commented Jun 4, 2015

@s1monw we flush before running optimize and it overwrites the segments_N file even if there are no segments. So, shouldn't this make such index upgraded?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants