jackson-datatypes-collections icon indicating copy to clipboard operation
jackson-datatypes-collections copied to clipboard

(guava) Better multiset serialization / deserialization

Open cowtowncoder opened this issue 8 years ago • 3 comments

(moved from https://github.com/FasterXML/jackson-datatype-guava/issues/51 by @devinrsmith)

Currently, multisets' serialization size is proportional to Multiset.size() as opposed to Multiset.entrySet().size().

For example, if I have do Multiset<String>.setCount("my_key", 1000), "my_key" is repeated 1000 times in the output. It would be much more appropriate if it behaved liked Map<String, Integer>.


I'm not familiar w/ the intricacies of jackson serialization / deserialization. I'd be pretty surprised if there is widespread use of serializing Multisets (using the existing jackson library)... I would have guessed a lot of other people would be bringing up this exact issue if they were using it. Does jackson ever create hard-breaks in backwards compatibility?

cowtowncoder avatar Mar 30 '16 02:03 cowtowncoder

Typically the way changes like this are handled is by introducing a new on/off Feature (for module or component) which defaults to old behavior, and can be changed to support new handling. But there are limited number of cases where we have just changed the setting, if we really think there is very low risk of problems.

This might be something to bring up on dev mailing list, esp. since there may be multiple ways data could be structured.

But I can definitely see why change would be useful here; it's just a question of how to best improve the situation.

cowtowncoder avatar Mar 30 '16 02:03 cowtowncoder

Second this issue. Just come across a production problem where the succinct serialization would be immensely useful. By reading these two posts and realizing jackson does not currently support succinct serialization, I have to move back to Map<T, Long>.

superxiao avatar Mar 08 '17 00:03 superxiao

PRs welcome.

cowtowncoder avatar Mar 08 '17 00:03 cowtowncoder