[
https://issues.apache.org/jira/browse/AVRO-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090592#comment-14090592
]
Dmitry Kovalev commented on AVRO-739:
-------------------------------------
bq. The extra string encodings seem like an unreasonably high price to pay in
development and test effort for human-readable output (I count 4 extra
type/logicalType pairs that need to be implemented by every library/application
implementing the spec). I think we'll end up with very few
libraries/applications implementing all of the types and encodings, which is
bad for interop whether you're using Avro for storage or IPC.
Well from IPC perspective the typical price to pay is 2-3 lines of code to
convert to and from the chosen internal representation (see e.g. my initial
comment on this topic), so I wouldn't fear that nobody will want to implement
this, and having a service which accepts both does make the clients' life
easier, especially scripted clients etc. However, I have already agreed before
that in other scenarios it may be best to insist on just one representation.
I think the way forward is to invite everyone who cares to "vote" for or
against including string representations in the spec. Then if there are more
votes "against" - please feel free to take my patch, remove the string bits
and resubmit.
My only concern would be the datetime-timezone type which had only string
representation, but I have a feeling that there won't be much interest in
including it either way, because it is relatively rare compared to timestamps
etc.
> Add Date/Time data types
> ------------------------
>
> Key: AVRO-739
> URL: https://issues.apache.org/jira/browse/AVRO-739
> Project: Avro
> Issue Type: New Feature
> Components: spec
> Reporter: Jeff Hammerbacher
> Fix For: 1.7.8
>
> Attachments: AVRO-739-datetime-spec.xml.patch, AVRO-739.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
