You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(note: regression partly due to #3373, reported f.ex as #4354 (but not just that))
So: if custom TypeIdResolver returns null from idFromValue() or idFromValueAndType(), result is that underlying JsonGenerator.writeTypePrefix() call is omitted. This may work for some cases, but won't for others, because necessary parts of structure are missing.
Conceptually the idea would be that null for Type Id means "do not add Type Id", but doing so cannot be done by simply skipping calls to JsonGenerators writeTypePrefix() and writeTypeSuffix(): rather, calls need to be made but these methods need to be aware of possibly missing type id and output whatever else is necessary.
EDIT: another way to describe this is that if idFromValue() / idFromValueAndType() returns null, serialization occurs AS IF non-polymorphic serialization was used. For As.PROPERTY / As.EXISTING_PROPERTY, for example, output would be similar but without "type": "typeId" entry in JSON Object; and for wrappers (As.ARRAY_WRAPPER / As.OBJECT_WRAPPER) no wrapping is added.
The text was updated successfully, but these errors were encountered:
Thinking this through again, I realized that what can and should be done depends on mechanism:
With As.PROPERTY (and As.EXISTING_PROPERTY), we CAN omit type id but if so, MUST add starting { (and closing }). This is the case I was mostly thinking
With As.WRAPPER_ARRAY, we CANNOT just omit entry, something must be written as first-element of array (null?) OR fail with exception.
With As.WRAPPER_OBJECT, we also CANNOT just omit entry, but we also cannot write null as property name. I guess we could write "" as key?
So (1) is fine, (2) somewhat and (3) less good.
Choice then is between failing on (2) and (3), or using placeholder.
My thinking is to go with placeholder; it is up to implementor of TypeIdResolver to either return null and get whatever we give, or avoid returning null.
Hmmh. Ok, actually, come to think of this... no, it should be possible to just omit Type Id write and make things work as if value was not polymorphic at all. That should work for all cases; but it cannot be done by simply avoiding calls to JsonGenerator.writeTypePrefix().
But there are two approaches, still:
Do it all in databind (TypeSerializerBase)
Use delegating, do it (mostly) in JsonGenerator
both approaches have their benefits.... need to think a bit more.
I think I will first try approach (1) and see how far that gets us.
(note: regression partly due to #3373, reported f.ex as #4354 (but not just that))
So: if custom
TypeIdResolver
returnsnull
fromidFromValue()
oridFromValueAndType()
, result is that underlyingJsonGenerator.writeTypePrefix()
call is omitted. This may work for some cases, but won't for others, because necessary parts of structure are missing.Conceptually the idea would be that
null
for Type Id means "do not add Type Id", but doing so cannot be done by simply skipping calls toJsonGenerator
swriteTypePrefix()
andwriteTypeSuffix()
: rather, calls need to be made but these methods need to be aware of possibly missing type id and output whatever else is necessary.EDIT: another way to describe this is that if
idFromValue()
/idFromValueAndType()
returnsnull
, serialization occurs AS IF non-polymorphic serialization was used. ForAs.PROPERTY
/As.EXISTING_PROPERTY
, for example, output would be similar but without"type": "typeId"
entry in JSON Object; and for wrappers (As.ARRAY_WRAPPER
/As.OBJECT_WRAPPER
) no wrapping is added.The text was updated successfully, but these errors were encountered: