SeparatorStyle option to avoid flattening arrays of primitive types#13
SeparatorStyle option to avoid flattening arrays of primitive types#13jdub wants to merge 2 commits intojeremywohl:masterfrom
Conversation
Normally,
{"a": [1, 2, 3], "m": {"key": "value"}}
would be flattened to,
{"a.0": 1, "a.1": 2, "a.2": 3, "m.key": "value"}
But in many cases, it's preferable to leave arrays of primitive types (such
as numbers and strings) as they are, e.g.
("a": [1, 2, 3], "m.key": "value"}
The new SeparatorStyle.DoNotFlattenPrimitiveArrays option is off by default
so the default behaviour doesn't change. Sadly, that's also why it has to be
an ugly negative option.
|
Hi Jeff. Thanks for your patch. Can you explain the use case for this? Re the patch, I assume you were trying to avoid a breaking change with this option in SeparatorStyle, where it really belongs as a call param? |
|
Yeah – I have a destination that can't really handle structure (objects), but is totally fine with arrays of primitives. (I'd even argue that this is a nicer default, because flattened arrays look uuuuugly. But others might require flatness more than they desire beauty. 😄) |
|
A seperator style with "don't flatten arrays" option would be useful (in my case I also need to include bool and nil values to use this PR). I'm also in need of such a functionality. I can add a method on the map produced but it won't be efficient in performance. Please do take a look at my fork with SkipArrays |
|
@AtakanColak Say more about bool and nil -- I don't see that in your patch. |
|
@jeremywohl It has been almost a year so I can't remember. Might even delete my fork sometime. |
Normally,
would be flattened to,
But in many cases, it's preferable to leave arrays of primitive types (such as numbers and strings) as they are, e.g.
The new SeparatorStyle.DoNotFlattenPrimitiveArrays option is off by default so the default behaviour doesn't change. Sadly, that's also why it has to be an ugly negative option.