Closed negokaz closed 1 year ago
I'm currently travelling and when I get back, I have higher priority items to look at. Using tuples for data binding is supported but not encouraged. Could you use a case class? The JSON will look a little different but case classes are the Scala norm for data binding. You could also try testing with a newer version of this lib. There are also numerous alternative libs out there if this one doesn't suit your needs.
In particular, trying with 2.14.2 (or 2.15.0-rc2) would be easy step to see that problem still occurs. 2.12 is bit old version.
@pjfanning Thank you for your reply. I understand your situation. We will try to use case class instead of tuples.
I haven't check the deserialization code yet but serialization seems to work (which is a start) - https://github.com/FasterXML/jackson-module-scala/commit/1741f14197ff3c59c14b2cfc8bc73286ba124636
@cowtowncoder I tried this deserialization case and the issue is happening in jackson-databind StringDeserializer.
This test case works with scala.Option
jackson-databind StringDeserializer blows up when it sees null
. I'd happily accept back Java null
in this case, because an Option can handle nulls. Is there any way to create a jackson-databind StringDeserializer that accepts nulls?
at com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1280)
at com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:73)
at com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:11)
@cowtowncoder I added this check in the jackson-module-scala code (https://github.com/FasterXML/jackson-module-scala/commit/eb55d7a3e432390c57a4e785556953ea2e534b7a) so that I can catch the fact the JSON value is null before invoking the inner deserializer.
@pjfanning Contract with jackson-databind
is that the "parent" deserializer is to handle null
tokens: so, for example, StringDeserializer
never sees null
but only non-null tokens.
In case of POJO properties, for example, BeanDeserializer
decodes from null
. Same is true for CollectionDeserializer
, array deserializers etc. Original idea was to reduce work for most deserializers (so like StringDeserializer
need not consider this case in any way) but in the end not sure trade-off was correct one. But it is the design.
Given this, TupleDeserializer
needs to handle null
s for fields and NOT delegate to JsonDeserializer
. I can dig up examples if necessary; there's some complexity in providing "null replacement" values.
Deserializing a tuple that contains
Some
values succeeds. However, a MismatchedInputException will be thrown during deserialization If the tuple containsNone
values.Version
Actual behavior
The test case
"deserialize OptionalTupleHolder that has 'None' values"
fails.Details of MismatchedInputException
Expected behavior
The json
{"tuple":[null,null]}
is deserialized toOptionalTupleHolder((None, None))
without any Exceptions.