Skip to content

Conversation

@jpountz
Copy link
Contributor

@jpountz jpountz commented Feb 28, 2019

This is similar to the work that has been done on 7.x to make typeless API calls
work on indices that have types, except that this commit doesn't introduce
typeless calls, eg. the REST API spec or REST handlers haven't been updated.

It only affects the get, index, update, delete and bulk APIs. Other APIs that
require types such as explain or termvectors are left unchanged.

This is necesarry to allow for rolling upgrades from 6.7 to 7.x while internal
indices might remain queried during upgrade by nodes that are on either version.

Closes #39469

This is similar to the work that has been done on 7.x to make typeless API calls
work on indices that have types, except that this commit doesn't introduce
typeless calls, eg. the REST API spec or REST handlers haven't been updated.

It only affects the get, index, update, delete and bulk APIs. Other APIs that
require types such as explain or termvectors are left unchanged.

This is necesarry to allow for rolling upgrades from 6.7 to 7.x while internal
indices might remain queried during upgrade by nodes that are on either version.

Closes elastic#39469
@jpountz jpountz added >feature :Distributed Indexing/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. v6.7.0 labels Feb 28, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

Copy link
Contributor

@jtibshirani jtibshirani left a comment

Choose a reason for hiding this comment

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

Thanks @jpountz, I left some comments but it looks very close to me. Except for the point around 'routing' below, all changes we tracked in #37450 seem to be reflected here.

I had two additional questions:

  • Would it be worth adding light tests that use _doc with the transport client? That is the functionality we're actually adding here (and that ML + others will be depending on), so it might be nice to have dedicated tests.
  • It could be worth catching up with someone from the distributed team to see if any issues stand out to them, or they expect any differences between 6.7 and 7.0. It's very much up to you, I'm just suggesting this as we don't have as much time to let this 'bake' in CI for 6.7 in order to catch tricky issues.

* being used in the mappings. This allows typeless APIs such as 'index' or 'put mappings'
* to work against indices with a custom type name.
*/
public String resolveDocumentType(String type) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Small comment, but would it make sense to always call this as part of the IndexMetaData#mappingOrDefault method, instead of doing mappingOrDefault(indexMetaData.resolveDocumentType...) at each call site? That matches what happens on 7.x slightly more closely, and this could become package-private for testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

7.x is a bit simpler since this method no longer takes a type parameter. I considered having it as part of mappingOrDefault but then it felt wrong to not have this logic in mapping as well, while the automatic replacement does not always make sense for call sites of the mapping method such as MapperService#assertMappingVersion.

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

assertEquals("the number of source shards [2] must be a factor of [3]", iae.getMessage());
}

public void testResolveDocumentType() throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for these great unit tests!

assert versionType.validateVersionForWrites(version);

String resolvedType = mapperService.resolveDocumentType(sourceToParse.type());
if (resolvedType != sourceToParse.type()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this is a string comparison, it would be good to switch to resolvedType.equals(sourceToParse.type()) == false.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK I'l do that.

: "op term [ " + opPrimaryTerm + " ] > shard term [" + getOperationPrimaryTerm() + "]";
assert versionType.validateVersionForWrites(version);

String resolvedType = mapperService.resolveDocumentType(sourceToParse.type());
Copy link
Contributor

Choose a reason for hiding this comment

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

Small comment, but I am wondering why this change is structured slightly differently than it is on master -- it just looks like a refactor to me, and that nothing has changed in terms of functionality. If that's true, then maybe it's worth keeping it in the same structure so the code lines up better between versions (even if it's a bit less elegant)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

: "op term [ " + opPrimaryTerm + " ] > shard term [" + getOperationPrimaryTerm() + "]";
assert versionType.validateVersionForWrites(version);

type = mapperService.resolveDocumentType(type);
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 wondering why we need this type resolution here (which doesn't appear on master either)? To me it looks like resolution is already handled in the individual calls to docMapper and prepareDelete.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for catching this, it was probably only useful in an earlier version of the change.

.put("index.number_of_replicas", 0).build();
createIndex("index", settings, "some_type", "_routing", "required=true");

expectThrows(RoutingMissingException.class,
Copy link
Contributor

Choose a reason for hiding this comment

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

I didn't see any changes to 'required routing' for delete, update, or get -- I think we might need to resolve the type in some additional places.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch.

@jpountz jpountz requested a review from dnhatn March 1, 2019 14:12
@jpountz
Copy link
Contributor Author

jpountz commented Mar 1, 2019

@dnhatn I added you as a reviewer since you dug the bug about duplicate translog entries. If you could take a look - even after merge in case Julie approves changes before you have a chance to review - this would be great.

Copy link
Contributor

@jtibshirani jtibshirani left a comment

Choose a reason for hiding this comment

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

This looks good to me with the latest changes. I'm also happy if you want to merge now, and have @dnhatn review post-merge.

@jpountz
Copy link
Contributor Author

jpountz commented Mar 1, 2019

Thanks @jtibshirani. @dnhatn I'll merge this now, but I'm still interested in your opinion when you have a chance to look.

@jpountz jpountz merged commit f14405a into elastic:6.7 Mar 1, 2019
@jpountz jpountz deleted the feature/typeless_67 branch March 1, 2019 16:33
Copy link
Member

@dnhatn dnhatn left a comment

Choose a reason for hiding this comment

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

LGTM.

@jpountz
Copy link
Contributor Author

jpountz commented Mar 1, 2019

Thank you @dnhatn !

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

Labels

blocker :Distributed Indexing/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. >feature v6.7.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants