[
https://issues.apache.org/jira/browse/AVRO-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364945#comment-17364945
]
Scott commented on AVRO-3160:
-----------------------------
I think one way to support this (as well as many other types of logical types
that aren't defined in the specification) is to make sure that each of the avro
libraries has a way for users to register their own custom logical type
handlers.
For example, right now the logical type for date uses the underlying int type
for encoding. However, someone may want to use a string as the underlying type
so that if they encode to JSON it's easy to read the date. All that should be
necessary is for the user to write an encoder function, a decoder function, and
then register those functions to a new logical type. We've done this on the
fastavro library and I think it works pretty well:
https://fastavro.readthedocs.io/en/latest/logical_types.html#custom-logical-types
> Decimal logical type for strings
> --------------------------------
>
> Key: AVRO-3160
> URL: https://issues.apache.org/jira/browse/AVRO-3160
> Project: Apache Avro
> Issue Type: New Feature
> Components: java
> Reporter: Artur Kalimullin
> Priority: Major
>
> Currently in avro there is just one way to represent BigDecimal: using bytes
> type with decimal logical type.
> Unfortunately, it's not really convenient to use in non-java environments (we
> currently have services in java and PHP that are communicating using avro).
> As an alternative, string could be used to represent decimal number without
> loosing precision and that's how we are doing it now. I propose to add
> logical type decimal to the type string to be able to use BigDecimal directly
> without converting it on client side.
> I could create a PR for that but wanted to know your opinion first about it,
> would you consider merging it? (I guess that's a question to [~rskraba])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
