Serializing map as list of pairs instead of having a key deserializer

[Benson Margulies]

Given a 

Map<somethingcomplex, value>

I'd rather just have it serialize as 

[ [ k, v], [ k, v] ...]

Is there a quick path here, or do I need a full custom setup?

[Tatu Saloranta]

There isn't anything to do exactly that, but I think use of Converters with intermediate type (Pair for List<Pair<K,V>>) might simplify the task. Converter can then handle conversion from Map to List<Pair>, Jackson serialize that using default mechanics.

-+ Tatu +-

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To post to this group, send email to jackso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Benson Margulies]

Converters are new to me :-)

[Tatu Saloranta]

Right, not as well known as others. Couple of ways to use it:

1. Use of annotations, @JsonSerialize(converter=....), @JsonDeserialize(converter=...) (either on type or for property)

2. Use StdDelegatingSerializer (instantiate, or sub-class), register via module.

Converters were briefly mentioned along with 2.2 release (2 years ago) at:

http://www.cowtowncoder.com/blog/archives/2013/08/entry_480.html

-+ Tatu +-

[Jon Harper]

Hi, sorry for digging up this old post. This seems like not such a rare case. Is there a way to do it without any code (reusing existing standard converters) today ?

I don't care if it's [ [ k, v], [ k, v] ...] or [ { key: k, value: v}, { key: k, value: v},...], or even [{ myname: k, myothername: v}, { myname: k, myothername: v}...]
On deserialization, I don't care about what happens if the input has duplicates keys.

I think it's worth documenting in the main site (maybe it is and I missed it ?). Actually I think that relying on toString() by default to serialize maps<Complex,X> is surprising, and maybe it's worth adding a global option to objectmapper to choose to convert all the maps<ComplexTypes, X> into lists of key value pairs ? 

Thanks in advance,

[Tatu Saloranta]

On Fri, Jun 18, 2021 at 7:30 AM Jon Harper <jon.ha...@gmail.com> wrote:
>
> Hi, sorry for digging up this old post. This seems like not such a rare case. Is there a way to do it without any code (reusing existing standard converters) today ?

I am not 100% sure. There isn't anything specifically designed for
this; however, there's both `MapEntrySerialzier` and
`MapEntryDeserializer` so pieces are there that might allow composing
handling. Especially serialization could be composable.
But I have not tested if it possible to easily reuse these.

> I don't care if it's [ [ k, v], [ k, v] ...] or [ { key: k, value: v}, { key: k, value: v},...], or even [{ myname: k, myothername: v}, { myname: k, myothername: v}...]
> On deserialization, I don't care about what happens if the input has duplicates keys.

Right,but my guess is that there would be many others with different
preferences. :)
(that is, if a specific choice is introduced, the very first RFE would
be to add another alternative)

> I think it's worth documenting in the main site (maybe it is and I missed it ?). Actually I think that relying on toString() by default to serialize maps<Complex,X> is surprising, and maybe it's worth adding a global option to objectmapper to choose to convert all the maps<ComplexTypes, X> into lists of key value pairs ?

Given that JSON only allows String keys, the choice would typically be
either relying on `toString()` or throwing an exception; I could see
an option that would force throwing an exception to prevent surprises
about inability to deserialize such keys.

Now... I kind of do like the concept of transformation at a high
level. There would be challenges as (de)serializer type
parameterization would change for conversion; possibly this could be
done by reusing mechanism(s) used for Converters.

Besides this, there is the question of API for users: what I have
learned over time is that it makes a lot of sense to have multiple
levels of applicability; typically something like:

1. Global default
2. Per-type default
3. Per-property override(s)

Doing this is easiest with `@JsonFormat` settings (possibly including
JsonFormat.Feature on/off settings).
This assumes there'd be just a single way to translate Map into
Collection (JSON Object into JSON Array); further choices
would get a bit complicated.

I would be open to contributions here, if anyone is interested. I
probably will not have time myself to work on this in near future.

-+ Tatu +-

> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/7cb89cd2-f7a7-44ed-9132-5784edbe1366n%40googlegroups.com.