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 merge for PUT not working if type changes #2130

Closed
odrotbohm opened this issue Apr 4, 2022 · 0 comments
Closed

Polymorphic merge for PUT not working if type changes #2130

odrotbohm opened this issue Apr 4, 2022 · 0 comments
Assignees
Labels
type: bug A general bug

Comments

@odrotbohm
Copy link
Member

Given the following type arrangement:

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "type")
@JsonSubTypes({
		@JsonSubTypes.Type(value = First.class, name = "first"),
		@JsonSubTypes.Type(value = Second.class, name = "second")
})
class Base {
  @JsonIgnore String ignored;
  String common;
}

class First extends Base {
  String first;
}

class Second extends Base {
  String second;
}

class Wrapper {
  Base base;
}

, the original state of the resource being:

Wrapper { base : First { ignored : "ignoredValue", common : "commonValue", first : "firstValue" } }

represented as

{
  "base" : {
    "type" : "first",
    "common" : "commonValue"
    "first" : "firstValue"
  }
}

and a PUT request with this body

{
  "base" : {
    "type" : "second",
    "second" : "secondValue"
  }
}

we expect to end up with server state equivalent to:

Wrapper { base : Second { ignored : "ignoredValue", second : "secondValue" } }

most notably, the type of the inner object has changed from First to Second, the submitted state of the second property has been applied and the common value has been removed (PUT semantics) but the value of the unexposed ignored property has been properly transferred to the new instance.

This is currently broken as the object mapping tries to bind the values of the new object Second to the instance of the old one and ultimately doesn't apply the type change unless the class is annotated with Spring Data's @Immutable.

@odrotbohm odrotbohm added this to the 3.5.11 (2021.0.11) milestone Apr 4, 2022
@odrotbohm odrotbohm added the type: bug A general bug label Apr 4, 2022
@odrotbohm odrotbohm self-assigned this Apr 4, 2022
odrotbohm added a commit that referenced this issue Apr 4, 2022
We now replace the original value of polymorphic properties with the newly deserialized one if the type of the new one is different from the old one. We still copy all JSON ignored properties to the new instance to make sure that non-exposed, server-side state is retained. We apply the same handling for explicitly immutable source and/or target types.

Fixes #2130.
odrotbohm added a commit that referenced this issue Apr 4, 2022
We now replace the original value of polymorphic properties with the newly deserialized one if the type of the new one is different from the old one. We still copy all JSON ignored properties to the new instance to make sure that non-exposed, server-side state is retained. We apply the same handling for explicitly immutable source and/or target types.

Fixes #2130.
odrotbohm added a commit that referenced this issue Apr 4, 2022
We now replace the original value of polymorphic properties with the newly deserialized one if the type of the new one is different from the old one. We still copy all JSON ignored properties to the new instance to make sure that non-exposed, server-side state is retained. We apply the same handling for explicitly immutable source and/or target types.

Fixes #2130.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

1 participant