Skip to content

Simple and concise way to preserve unknown properties when deserializing JSON #2701

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

Closed
Flavien opened this issue Jun 4, 2024 · 4 comments
Closed

Comments

@Flavien
Copy link

Flavien commented Jun 4, 2024

What is your use-case and why do you need this feature?

We need a simple and concise way to no lose unknown properties when deserializing JSON. The use case is a process reading a JSON file, with some extra attributes it doesn't know about, makes some changes to the document (leaving alone the attributes it doesn't know about), and re-serialize the JSON file with the modifications.

If unknown properties are just ignored and discarded during deserialization, any extra fields that are not known by the program during deserialization will be silently lost when re-serializing.

Describe the solution you'd like

We need the ability to collect unknown properties into a Map while deserialising, and write them back when serialising. Lots of JSON libraries support this (e.g. in .NET).

@Flavien Flavien added the feature label Jun 4, 2024
@pdvrieze
Copy link
Contributor

pdvrieze commented Jun 4, 2024

  • I assume you mean here that you wish to do this in a way that you add a val otherProperties: Map<String,JsonObject> property with a marker annotation to a Serializable class, and then this property is automatically populated by all "extra" properties.
  • I also assume that you don't wish to write a custom serializer for this behaviour.

I would say that such a feature is worthwhile (in Json) and I've had it in the XML format for a long time (where namespaces make this much more robust). It is not particularly hard to implement.

@Flavien
Copy link
Author

Flavien commented Jun 4, 2024

Yes that's exactly it.

@pschichtel
Copy link
Contributor

isn't this similar to #1978 ?

@sandwwraith
Copy link
Member

Yes, I think it can be closed as duplicate of #1978

@sandwwraith sandwwraith closed this as not planned Won't fix, can't repro, duplicate, stale Jun 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants