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

Polymorphic subtype deduction ignores defaultImpl attribute #3055

Closed
drekbour opened this issue Feb 13, 2021 · 8 comments
Closed

Polymorphic subtype deduction ignores defaultImpl attribute #3055

drekbour opened this issue Feb 13, 2021 · 8 comments
Assignees
Milestone

Comments

@drekbour
Copy link
Contributor

Describe the bug
A class with @JsonTypeInfo(use = JsonTypeInfo.Id.DEDUCTION, defaultImpl = Animal.class) that fails to deduce a solo candidate should use defaultImpl

Version information
2.12.0

To Reproduce
TBA see #2976

Expected behavior
In the absence of a single candidate, defaultImpl should be the target type regardless of suitability.

Additional context
The current deduction process does not support pojo-hierarchies such that the absence of child properties infers a parent type. That is, every deducible subtype MUST have some unique properties and the input data MUST contain said unique properties to provide a positive match.

@drekbour drekbour added the to-evaluate Issue that has been received but not yet evaluated label Feb 13, 2021
@drekbour
Copy link
Contributor Author

Please assign to me. I'm happy to support my addition :)

@cowtowncoder
Copy link
Member

Great! Sounds like this could go in 2.12 branch (might make it in 2.12.2 depending on timing), if it feels like low-risk addition (seems to me that'd be the case). Otherwise should go in 2.13 which would get bit longer to get out.

@cowtowncoder cowtowncoder added 2.12 and removed to-evaluate Issue that has been received but not yet evaluated labels Feb 13, 2021
@drekbour
Copy link
Contributor Author

See PR #3057. However

To discuss: Quality of feedback is reduced
(a) with no defaultImpl, we now report only Cannot deduce unique subtype and not even the number of candidates. This is a bit weak but hard to correct without a larger change to the inherited error handling.
(b) with successful defaultImpl, nobody mentions that deduction failed. I think this is expected
(c) with unsuccessful defaultImpl, nobody mentions that deduction failed. I think this is poor.

I stumbled on (c) as my superclass was abstract (and after that because I had not disabled FAIL_ON_UNKNOWN_PROPERTIES). I can quite imagine users doing similar things and never testing that their defaultImpl works (DEDUCTION mode is after all a little bit of a "lazy model").

I predict confusion as to why Jackson is complaining about a secondary issue and completely masking the original cause (deduction failure).

@cowtowncoder next step is your call but I'd rather include what we have here as there's other work to be done in this area

@cowtowncoder
Copy link
Member

Hmmh. Yes, I see; while fixing the issue wrt defaultImpl is good, I really don't like losing contextual information. And although it is likewise good to allow graceful handling via handleXxx() methods (instead of directly failing), handleMissingTypeId() was not design with deduction in mind.
Handler itself does get TypeIdResolver, but handleMissingTypeId() is designed around missing info and not... incomplete/ambiguous one.

For 2.12 this may be best we could do; for 2.13 callbacks could possibly be improved. For example, could add alternative handleFailedTypeIdDeduction() which in turn could either call either existing handleMissingTypeId() in DeserializationProblemHandler or add a new method there as well.

I suspect that we might be able to solve some of these (esp (a)) with more changes to base impl TypeDeserializerBase... but that does run risk of regression for anyone subclassing with custom implementation (although that is not part of intended public API, not a supported extension point).

So with that, @drekbour, do you think splitting improvements b/w 2.12 and 2.13 makes sense?
I can definitely live with that.

@drekbour
Copy link
Contributor Author

I think defaultImpl for both (b) and (c) works the same for other subtype modes does it not?
The loss in (a) is minor (the count of candidates) as it already doesnt include anything concrete that would help fix a problem much. That should be fixed but yes, not here

@cowtowncoder
Copy link
Member

@drekbour Yes, defaultImpl is used similarly in that if the type cannot be resolved for whatever reason, it will be used; my concern is not with the logic. But the exception message should better indicate the reason for failure when defaultImpl is missing: and in that case it is wrong to say "type id is missing" for Deduction since type id is never provided (nor could or should be). But there is important contextual information provided up until now about potential types.

So my concern is only about actual fail messages. Those should be adjustable based on "type id type" (resolution mechanism), possibly just having special logic for Deduction type.

@drekbour
Copy link
Contributor Author

drekbour commented Feb 18, 2021

Have updated this PR with a simple change to allow contextual failure reports - reinstating the original text. I have not attempted to write a better report as that would be a separate PR with new discussion (enough here already!).

@cowtowncoder
Copy link
Member

@drekbour thanks! That sounds good. Agree, first things first; and for 2.12.x patches fixing missing defaultImpl handling sounds good. I'll have a look at PR.

@cowtowncoder cowtowncoder added this to the 2.12.2 milestone Feb 18, 2021
@cowtowncoder cowtowncoder changed the title Polymorphic subtype deduction ignores defaultImpl attribute Polymorphic subtype deduction ignores defaultImpl attribute Feb 18, 2021
cowtowncoder added a commit that referenced this issue Feb 18, 2021
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

No branches or pull requests

2 participants