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

Deprecate types in create index requests. #37134

Merged

Conversation

jtibshirani
Copy link
Contributor

@jtibshirani jtibshirani commented Jan 4, 2019

From #29453 and #37285, the include_type_name parameter was already present and defaulted to false. This PR makes the following updates:

  • Add deprecation warnings to RestCreateIndexAction, plus tests in RestCreateIndexActionTests.
  • Add a typeless 'create index' method to the Java HLRC, and deprecate the old typed version. To do this cleanly, I created new CreateIndexRequest and CreateIndexResponse objects that differ from the existing server ones.

@jtibshirani jtibshirani added :Search Foundations/Mapping Index mappings, including merging and defining field types >deprecation v7.0.0 labels Jan 4, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@jtibshirani jtibshirani force-pushed the deprecate-types-in-create-index branch 3 times, most recently from 2788ffe to 6041a84 Compare January 4, 2019 05:26
@jtibshirani
Copy link
Contributor Author

@elasticmachine run gradle build tests 1

@jtibshirani jtibshirani force-pushed the deprecate-types-in-create-index branch from aed279e to c3cb3b2 Compare January 18, 2019 03:49
@jtibshirani jtibshirani force-pushed the deprecate-types-in-create-index branch from c3cb3b2 to 457a69e Compare January 18, 2019 05:29
@jtibshirani
Copy link
Contributor Author

@elasticmachine run gradle build tests 1
@elasticmachine run gradle build tests 2

Copy link
Member

@cbuescher cbuescher left a comment

Choose a reason for hiding this comment

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

@jtibshirani I think the general approach to provide two variants, a typed and an un-typed call in the HLRC and to use other Request-Classes for the "new" calls is fine. In this case I'm wondering if we can avoid copying to much code from server, unless we really need it. I left some comments along those lines.

import static org.elasticsearch.test.ESTestCase.randomBoolean;
import static org.elasticsearch.test.ESTestCase.randomIntBetween;

public final class RandomCreateIndexGenerator {
Copy link
Member

Choose a reason for hiding this comment

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

I understand that this helper creates the new "client-side" CreateIndexRequest, but I'm a bit reluctant to copy yet another full over from test.frameworks. Can you somehow create a simple converter from server-side CreateIndexRequest to client side ones instead? We could then reuse the existing RandomCreateIndexGenerator.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a nice idea, I'll try it out. One note is that we'll have to swap out the mappings, since client-side CreateIndexRequest expects typeless mappings, whereas the server-side one always expects typed mappings.

@jtibshirani
Copy link
Contributor Author

@cbuescher this is ready for another look.

Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

great work. I called out something that was brought over from server (all of the methods to set source), but im not sure we should do anything about it. Im torn between cleaning these client side objects up now, or waiting till we can generate them, and trying to keep them as close to server side as possible, for now. I hate to see them diverge, but I also hate to add all this stuff to client that we will have to maintain. I think im still leaning toward removing whatever we dont think is useful to make the classes as lean as possible, and it means that people wont use methods that dont exist! Im also cool w/ extending a server side class if there is 0 tangible difference, for now. Making the package change is ++.

*
* Note that the mapping definition should *not* be nested under a type name.
*/
public CreateIndexRequest source(byte[] source, int offset, int length, XContentType xContentType) {
Copy link
Contributor

Choose a reason for hiding this comment

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

do we need all these ways to set source here?

Copy link
Contributor

Choose a reason for hiding this comment

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

in general, i think we should try to clean up these classes if we can, so that people have less ways to set these values on the client side objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll take a stab at removing some of the less important setters on this class.

@jtibshirani
Copy link
Contributor Author

Thanks @hub-cap for the review! I tried to address your comments.

I think im still leaning toward removing whatever we dont think is useful to make the classes as lean as possible, and it means that people wont use methods that dont exist!

I didn't have a great intuition as to how far to go with the clean-up. I ended up removing two source methods that didn't seem useful in a client context. Another option is to remove all source methods, so users must use the individual setters for mappings, aliases, etc., but I was hesitant to do this because I saw a source method being advertised in the HLRC create index documentation. Please let me know if you have other suggestions for cleaning this up.

@jtibshirani
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/1

2 similar comments
@jtibshirani
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/1

@jtibshirani
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/1

Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

I would be ok with removing all but the source(BytesReference, ... call, but its not that big of a deal. These will, hopefully, one day be replaced by concrete objects so we can leave them all for now.

Copy link
Member

@cbuescher cbuescher left a comment

Choose a reason for hiding this comment

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

Thanks @jtibshirani for adressing my comments as well. LGTM

@jtibshirani jtibshirani merged commit e1d8df4 into elastic:master Jan 24, 2019
@jtibshirani jtibshirani deleted the deprecate-types-in-create-index branch January 24, 2019 21:17
jtibshirani added a commit that referenced this pull request Jan 24, 2019
From #29453 and #37285, the include_type_name parameter was already present and defaulted to false. This PR makes the following updates:
* Add deprecation warnings to RestCreateIndexAction, plus tests in RestCreateIndexActionTests.
* Add a typeless 'create index' method to the Java HLRC, and deprecate the old typed version. To do this cleanly, I created new CreateIndexRequest and CreateIndexResponse objects that differ from the existing server ones.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>deprecation :Search Foundations/Mapping Index mappings, including merging and defining field types v6.7.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants