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

Remove tricky switch in bulk #80624

Merged
merged 5 commits into from
Nov 11, 2021
Merged

Conversation

nik9000
Copy link
Member

@nik9000 nik9000 commented Nov 10, 2021

Now that we have #79394 and #79472 the switch statement in
TransportBulkAction is mostly just assigning routing and doing some
stuff with INDEX and CREATE requests. This pulls the routing stuff into
a single call and calls out the index-only stuff. Now, at least, it's
clearer that only INDEX and CREATE are special.

Now that we have elastic#79394 and elastic#79472 the switch statement in
`TransportBulkAction` is mostly just assigning routing and doing some
stuff with INDEX and UPDATE requests. This pulls the routing stuff into
a single call and calls out the index-only stuff. Now, at least, it's
clearer that only INDEX and UPDATE are special.
@nik9000 nik9000 added >non-issue :Distributed Indexing/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. v8.1.0 labels Nov 10, 2021
@elasticmachine elasticmachine added the Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. label Nov 10, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

@arteam
Copy link
Contributor

arteam commented Nov 10, 2021

@elasticmachine update branch

@arteam
Copy link
Contributor

arteam commented Nov 10, 2021

Sorry for breaking the BWC tests, it's fixed now in master in 77a8ab5

Copy link
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

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

LGTM

clearer that only INDEX and UPDATE are special.

I think you meant INDEX and CREATE?

prohibitAppendWritesInBackingIndices(docWriteRequest, metadata);
prohibitCustomRoutingOnDataStream(docWriteRequest, metadata);
IndexRequest indexRequest = (IndexRequest) docWriteRequest;
indexRequest.resolveRouting(metadata);
Copy link
Member

Choose a reason for hiding this comment

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

I think the resolveRouting(...) method can now also be removed from IndexRequest class? (looks this was the only usage).

Copy link
Member Author

Choose a reason for hiding this comment

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

Doh! I had done that when I was working on it and had lost it in the shuffle. I'll add it back

Copy link
Contributor

@henningandersen henningandersen left a comment

Choose a reason for hiding this comment

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

LGTM, left two optional comments.

throw new AssertionError("request type not supported: [" + docWriteRequest.opType() + "]");
if (docWriteRequest.opType() == OpType.CREATE || docWriteRequest.opType() == OpType.INDEX) {
prohibitAppendWritesInBackingIndices(docWriteRequest, metadata);
prohibitCustomRoutingOnDataStream(docWriteRequest, metadata);
Copy link
Contributor

Choose a reason for hiding this comment

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

@martijnvg I wonder if it is not a bug that we do not check this for all request types, including update/delete? Maybe better handled in a follow-up, but would be nice to move out of this "if". And perhaps then let prohibitAppendWritesInBackingIndices handle the ops itself to simplify this code (the filter for CREATE/INDEX here is really only partial anyway, so might as well do that inside the method).

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I think prohibitCustomRoutingOnDataStream() should be checked for all types of request, irregardless whether these target the data stream of one of the backing indices. I think only prohibitAppendWritesInBackingIndices() should be checked in this if statement. I can work on that in a followup.

Copy link
Member Author

Choose a reason for hiding this comment

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

Neat! I was hoping writing it like this would make stuff like this more obvious. I'll leave this to @martijnvg's follow up though.

}
docWriteRequest.routing(metadata.resolveWriteIndexRouting(docWriteRequest.routing(), docWriteRequest.index()));
if (docWriteRequest.opType() == OpType.CREATE || docWriteRequest.opType() == OpType.INDEX) {
((IndexRequest) docWriteRequest).process();
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not add DocWriteRequest.process() too to avoid the if here?

Copy link
Member Author

Choose a reason for hiding this comment

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

I was looking at that. Flipping it over and over like it was a serving bowl I didn't need at a yard sale. I'll put it back that way and see if you like.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah ha! The thing that was bothering me last time was that I tried to merge the alias routing setting into DocWriteRequest.process but that wasn't working right because we need to call DocWriteRequest.process on the data nodes after update requests have been translated. I didn't think to myself "what if I didn't try to merge those things?"

@nik9000
Copy link
Member Author

nik9000 commented Nov 11, 2021

I think you meant INDEX and CREATE?

👍

Copy link
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

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

LGTM 👍

Copy link
Contributor

@henningandersen henningandersen left a comment

Choose a reason for hiding this comment

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

LGTM.

@nik9000 nik9000 merged commit 4b81094 into elastic:master Nov 11, 2021
martijnvg added a commit to martijnvg/elasticsearch that referenced this pull request Nov 24, 2021
* Always check whether it is prohibited to use custom routing on a data stream.
* Always invoke prohibitAppendWritesInBackingIndices(...), but in the method check
  whether the operation is of type index or create.

Follow-up from elastic#80624.
martijnvg added a commit that referenced this pull request Nov 25, 2021
* Always check whether it is prohibited to use custom routing on a data stream.
* Always invoke prohibitAppendWritesInBackingIndices(...), but in the method check
  whether the operation is of type index or create.

Follow-up from #80624.
@wchaparro wchaparro assigned nik9000 and unassigned nik9000 Dec 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Indexing/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. >non-issue Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v8.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants