HHH-19964 Allow json serialization of Object valued attribute

[jrenaat]

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-19964

[jrenaat]

@beikov removing the Object type check on the FormatMapper toString/fromString methods makes it work, but with some noteworthy restrictions:
1/ it only works for jackson, jsonb serializes the object to an empty json string {}
2/ the roundtrip from the database comes with its own particular quirk: the db json string makes it effectively impossible to distinguish between anything other than Maps and Lists, i.e. Sets and Queues get serialized back to List, and Dictionary, to Map
So, do we want to, or can we even, improve this such that we can pass the correct type to jackson for deserialization or, given these restrictions, would it be wiser to disallow this kind of mapping?

[beikov]

1/ it only works for jackson, jsonb serializes the object to an empty json string {}

I'd say this is fine. What will happen during serialization/deserialization is up to the FormatMapper, so differences between implementations are to be expected.

2/ the roundtrip from the database comes with its own particular quirk: the db json string makes it effectively impossible to distinguish between anything other than Maps and Lists, i.e. Sets and Queues get serialized back to List, and Dictionary, to Map

That is also expected. JSON obviously only knows "object" and "array" and it is up to the configured ObjectMapper to decide how to serialize/deserialize data. Since serialization of anything that is an instance of Collection/Iterable is probable going to end up as JSON array, the natural deserialization is a List. Instances of type Map are serialized as JSON object, and deserialization to Object can be anything, from Map to JsonNode, but the details are up to the ObjectMapper configuration.

So, do we want to, or can we even, improve this such that we can pass the correct type to jackson for deserialization or, given these restrictions, would it be wiser to disallow this kind of mapping?

I don't think we can improve anything, nor should we. These "restrictions" are fine IMO and simply a result of the fact that a user chose to statically type Object rather than anything else. Similar "quirks" apply when users serialize a Map<String, Object> when they put values of type Long/Integer/Short/Byte or similar and it deserializes to some other Number type. If you want, you can add a warning to the documentation about these sharp edges, but who knows if people that run into such trouble will even read the documentation..

[jrenaat]

Waiting for resolution of https://hibernate.atlassian.net/browse/HHH-18572 to move this forward

[beikov]

Seems Oracle 19c doesn't like the changes in the test class. Can you please investigate by using e.g. Oracle 18 XE?

[beikov]

I changed the base branch to 7.2 now, because I merged your changes on main already as part of the support for type variables. Can you please drop the two commits from Steve?

[jrenaat]

I changed the base branch to 7.2 now, because I merged your changes on main already as part of the support for type variables. Can you please drop the two commits from Steve?

Sure ... i wonder where the heck those came from .... ?

[jrenaat]

I changed the base branch to 7.2 now, because I merged your changes on main already as part of the support for type variables. Can you please drop the two commits from Steve?

Sure ... i wonder where the heck those came from .... ?

I respond to myself: from the change to 7.2 ...

[beikov]

Sure ... i wonder where the heck those came from .... ?

I pulled them locally while looking at your PR and worked on top of them to add support for type variables.