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

Feature #2536 : "READ_ENUM_KEYS_USING_INDEX" to match "WRITE_ENUM_KEYS_USING_INDEX" #3764

Merged

Conversation

JooHyukKim
Copy link
Member

@JooHyukKim JooHyukKim commented Jan 29, 2023

Description

  • Add enum features to deserialize using enum index
  • Matches WRITE_ENUM_KEYS_USING_INDEX symmetrically, (test case included)

Related Issue : Need a Feature like "READ_ENUM_KEYS_USING_INDEX" #2536

Let me know for anything, cheers

@@ -417,6 +431,18 @@ private EnumResolver _getToStringResolver(DeserializationContext ctxt)
}
return res;
}

private EnumResolver _getIndexResolver(DeserializationContext ctxt) {
EnumResolver res = _byIndexResolver;
Copy link
Member

Choose a reason for hiding this comment

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

this form of double-checked locking is not thread-safe, see https://shipilev.net/blog/2014/safe-public-construction/

_byIndexResolver needs to be volatile

@JooHyukKim
Copy link
Member Author

JooHyukKim commented Jan 30, 2023

Thanks for the guidances guys! New version with all the points implmented/revised up

}
}
}
return _byNameResolver;
Copy link
Member

Choose a reason for hiding this comment

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

should be _byIndexResolver

@JooHyukKim JooHyukKim requested review from pjfanning and yawkat and removed request for pjfanning and yawkat January 30, 2023 15:24
@JooHyukKim JooHyukKim requested review from pjfanning and removed request for yawkat January 31, 2023 03:04
Copy link
Member

@pjfanning pjfanning left a comment

Choose a reason for hiding this comment

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

lgtm but will need @cowtowncoder's approval to merge

@JooHyukKim
Copy link
Member Author

@cowtowncoder do you have any other opinion on this PR?

@cowtowncoder
Copy link
Member

@cowtowncoder do you have any other opinion on this PR?

Unfortunately I haven't had time to look into it yet -- there's a big backlog of items. But I hope to have a look soon. Thank you for contributing this!

@cowtowncoder
Copy link
Member

Ok, one quick note: I do not want to add a new DeserializationFeature, as those should ideally be more general, not datatype-specific: I know a few already exists but I hope they eventually get moved out (for 3.0).

Instead I would like it added using EnumFeature.READ_ENUM_KEYS_USING_INDEX; similar to how new options have been added using JsonNodeFeature.
That should be about as easy to use and offers more extensibility (number of DeserializationFeature entries is limited to 31, f.ex).

@@ -126,7 +126,27 @@ public static EnumResolver constructUsingToString(DeserializationConfig config,
config.isEnabled(MapperFeature.ACCEPT_CASE_INSENSITIVE_ENUMS));
}

/**

Copy link
Member

Choose a reason for hiding this comment

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

Need to add Javadoc that includes @since 2.15 to indicate when method was added.

@cowtowncoder
Copy link
Member

Aside from DeserializationFeature -> EnumFeature, and need for minor addition of Javadocs (to indicate version public things were added in), looks pretty good! Good job.
Will be happy to merge after changes.

@JooHyukKim
Copy link
Member Author

JooHyukKim commented Feb 1, 2023

Crossed out all above because @cowtowncoder explained about enabling EnumFeature support more in the futurue.

> Ok, one quick note: I do not want to add a new `DeserializationFeature`, as those should ideally be more general, not datatype-specific: I know a few already exists but I hope they eventually get moved out (for 3.0).

I see, these feature are to be moved out. So do we not need this symmetry with I am curious about your opinion on this.

Instead I would like it added using EnumFeature.READ_ENUM_KEYS_USING_INDEX; similar to how new options have been added using JsonNodeFeature. That should be about as easy to use and offers more extensibility (number of DeserializationFeature entries is limited to 31, f.ex).

Just to be clear, are we keeping both, or just EnumFeature?
I am confused if I should remove first DeserializationFeature. READ_ENUM_KEYS_USING_INDEX before implementing just adding aEnumFeature ?

@JooHyukKim JooHyukKim requested review from cowtowncoder and yawkat and removed request for cowtowncoder and yawkat February 3, 2023 13:03
@cowtowncoder
Copy link
Member

Crossed out all above because @cowtowncoder explained about enabling EnumFeature support more in the futurue.

Right: this is about transitioning enum-related features (over time) to separate EnumFeature.
Existence of old settings is definitely bit confusing, thank you for picking this up here.

@cowtowncoder cowtowncoder merged commit d75496b into FasterXML:2.15 Feb 6, 2023
@cowtowncoder cowtowncoder added this to the 2.15.0 milestone Feb 6, 2023
@cowtowncoder
Copy link
Member

Thank you @JooHyukKim for contributing this -- I finally had time to merge it, and it will go in 2.15.0 release.

@JooHyukKim JooHyukKim deleted the #2536-READ_ENUM_KEYS_USING_INDEX branch May 22, 2023 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants