On Fri, Jun 18, 2021 at 7:30 AM Jon Harper <[email protected]> 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 +-

>
> Thanks in advance,
>
> On Thursday, June 25, 2015 at 8:41:01 PM UTC+2 [email protected] wrote:
>>
>> 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 +-
>>
>>
>> On Thu, Jun 25, 2015 at 11:34 AM, Benson Margulies <[email protected]> 
>> wrote:
>>>
>>> Converters are new to me :-)
>>>
>>> On Thu, Jun 25, 2015 at 2:33 PM, Tatu Saloranta <[email protected]> wrote:
>>>>
>>>> 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 +-
>>>>
>>>>
>>>> On Thu, Jun 25, 2015 at 8:57 AM, Benson Margulies <[email protected]> 
>>>> wrote:
>>>>>
>>>>> 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?
>>>>>
>>>>> --
>>>>> 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 [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> 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 [email protected].
>>>> To post to this group, send email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
> --
> 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 [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jackson-user/7cb89cd2-f7a7-44ed-9132-5784edbe1366n%40googlegroups.com.

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jackson-user/CAL4a10g1iMR%2Br6LpfSPW9z0Vjz0SPO5BYsnbicoF_jwqQkmwYw%40mail.gmail.com.

Reply via email to