You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently use of Header row (and manual construction of CsvSchema) assume that headers only specify name of column position. But there exists usage, wherein header line contain type mappings too:
name:string,enabled:boolean, ...
It would be great to support this.
There is an immediate problem with "type" definition: as things are, only a very limited set of types is recognized for CsvColumn. But we could divide implementation into two main parts:
Support mapping to existing small set of types (probably allowing case-insensitive type definition)
Support configurability of extension types, by providing converters from String value into target types.
For (2) there is also additional step needed: whereas we could expose JsonToken values for:
Strings
Numbers
Booleans
nulls
everything else would need to be exposed as JsonToken.VALUE_EMBEDDED_OBJECT.
But if so, any and all types could be supported -- as long as jackson-databind deserializers (JsonDeserializer impelmentations) consider possibility of embedded type.
Doing above is not trivial, but would be a very powerful mechanism for customized binding from CSV data. Some amount of duplication would likely result (for Converters) but that seems acceptable.
The text was updated successfully, but these errors were encountered:
Currently use of Header row (and manual construction of
CsvSchema
) assume that headers only specify name of column position. But there exists usage, wherein header line contain type mappings too:It would be great to support this.
There is an immediate problem with "type" definition: as things are, only a very limited set of types is recognized for
CsvColumn
. But we could divide implementation into two main parts:String
value into target types.For (2) there is also additional step needed: whereas we could expose
JsonToken
values for:everything else would need to be exposed as
JsonToken.VALUE_EMBEDDED_OBJECT
.But if so, any and all types could be supported -- as long as
jackson-databind
deserializers (JsonDeserializer
impelmentations) consider possibility of embedded type.Doing above is not trivial, but would be a very powerful mechanism for customized binding from CSV data. Some amount of duplication would likely result (for Converters) but that seems acceptable.
The text was updated successfully, but these errors were encountered: