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 all variants of a ParseField with no replacement #53722

Merged
merged 1 commit into from
Mar 18, 2020

Conversation

romseygeek
Copy link
Contributor

Sometimes we want to deprecate and remove a ParseField entirely, without replacement;
for example, the various places where we specify a _type field in 7x. Currently we can
tell users only that a particular field name should not be used, and that another name should
be used in its place. This commit adds the ability to say that a field should not be used at
all.

@romseygeek romseygeek requested a review from nik9000 March 18, 2020 12:33
@romseygeek romseygeek self-assigned this Mar 18, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (:Core/Infra/Core)

@romseygeek
Copy link
Contributor Author

Lots of tests were using anonymous DeprecationHandlers that did nothing. Rather than extend all of these with an extra method, I thought it was worth adding a static do-nothing instance on DeprecationHandler itself.

@@ -108,15 +118,17 @@ public boolean match(String fieldName, DeprecationHandler deprecationHandler) {
Objects.requireNonNull(fieldName, "fieldName cannot be null");
// if this parse field has not been completely deprecated then try to
// match the preferred name
if (allReplacedWith == null && fieldName.equals(name)) {
if (fullyDeprecated == false && allReplacedWith == null && fieldName.equals(name)) {
Copy link
Member

Choose a reason for hiding this comment

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

Would it be simpler to add something like:

if (fullyDeprecated) {
  deprecationHandler.usedDeprecatedField(fieldName);
  return true;
}

above this if statement?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We still need to check that one of the possible names matches so it's not quite as simple as that, unfortunately

Copy link
Member

Choose a reason for hiding this comment

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

Fair enough.

/**
* Ignores all deprecations
*/
DeprecationHandler IGNORE_DEPRECATIONS = new DeprecationHandler() {
Copy link
Member

Choose a reason for hiding this comment

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

👍

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -108,15 +118,17 @@ public boolean match(String fieldName, DeprecationHandler deprecationHandler) {
Objects.requireNonNull(fieldName, "fieldName cannot be null");
// if this parse field has not been completely deprecated then try to
// match the preferred name
if (allReplacedWith == null && fieldName.equals(name)) {
if (fullyDeprecated == false && allReplacedWith == null && fieldName.equals(name)) {
Copy link
Member

Choose a reason for hiding this comment

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

Fair enough.

@romseygeek romseygeek merged commit e23311c into elastic:master Mar 18, 2020
@romseygeek romseygeek deleted the deprecation/parse-field-full branch March 18, 2020 14:15
romseygeek added a commit that referenced this pull request Mar 18, 2020
…placement (#53722)

Sometimes we want to deprecate and remove a ParseField entirely, without replacement;
for example, the various places where we specify a _type field in 7x. Currently we can
tell users only that a particular field name should not be used, and that another name should
be used in its place. This commit adds the ability to say that a field should not be used at
all.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants