Open C-h-e-r-r-y opened 6 years ago
Ok, at high level I think this makes sense, and I thought there was an issue for it, but apparently not. It is something I have thought a bit about, although without coming to a conclusion.
Challenge here is that any-properties are really handled at databind level, without any knowledge of underlying format. So as-is, there is no way to really customize this for CSV use case. This means that:
So question would be that of how to map such extra data. Answer may have to vary between serialization, deserialization.
For deserialization one would either have to use synthetic names ("1", "2", templating, something), and that might work quite easily. Use of Collection
would seem to make sense, but in practice could only support Collection<String>
; and would be incompatible with existing logic of calling method once per extra property.
For serialization things might be easier, come to think of that... if there was a way to indicate special arrangement. Perhaps Jackson 3.0 could have capability introspection which would indicate alternate call for such extra data, for formats that do not have true name/value pairing at low level (CSV is positional and name binding is extra layer).
@amr Good point -- so it'd be due to issue 109 (from old repository) having been implemented.
The idea
Original Jackson has \@JsonAnySetter annotation which allow you deserializae any unknow fields into Map. Why not add this possibility for unknow columns? The setter could be
Collection<String>
with rest of column values or for Jackson compatibilityMap<String, Object>
for nested types (I do not know whether you support nested types during deseriablization) or simpleMap<String, String>
with keys as column order number. (just as idea)The implementation should write all column as they described in
JsonPropertyOrder
and all other put into annotation setter.The code
I have tried to run the following:
pom.xml snippet
The exception