[
https://issues.apache.org/jira/browse/AVRO-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15327760#comment-15327760
]
Sean Busbey commented on AVRO-1847:
-----------------------------------
{code}
public String conversionInstance(Schema schema) {
+ if (schema == null || schema.getLogicalType() == null) {
+ return "null";
+ }
+
if (LogicalTypes.date().equals(schema.getLogicalType())) {
return "DATE_CONVERSION";
} else if (LogicalTypes.timeMillis().equals(schema.getLogicalType())) {
return "TIME_CONVERSION";
} else if (LogicalTypes.timestampMillis().equals(schema.getLogicalType()))
{
return "TIMESTAMP_CONVERSION";
+ } else if
(LogicalTypes.Decimal.class.equals(schema.getLogicalType().getClass())) {
+ return "DECIMAL_CONVERSION";
}
- return "null";
+ throw new RuntimeException("Cannot find a conversion for logical type [" +
schema.getLogicalType() + "]");
}
{code}
why this change in behavior? what's the advantage over returning "null" when a
given logical type doesn't match our internal conversions? won't this limit the
ability of downstream folks to make their own version of hte specific compiler
with additional logical types? Essentially they'll have to change from handling
a null return to handling an exception for normal control flow.
(Including this change to RTE would also push me towards flagging this as 1.9+
only)
> IDL compiler uses ByteBuffer for decimal type even if logical type is
> supported
> --------------------------------------------------------------------------------
>
> Key: AVRO-1847
> URL: https://issues.apache.org/jira/browse/AVRO-1847
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.8.0
> Reporter: Yibing Shi
> Assignee: Yibing Shi
> Attachments: AVRO-1847.1.patch, AVRO-1847.2.patch, AVRO-1847.3.patch,
> AVRO-1847.4.patch
>
>
> Version 1.8.0 has added the support of logical types. A conversion class
> (Conversions.DecimalConversion) has also been added for decimal type.
> However, the IDL compiler still uses ByteBuffer for decimal types, which is
> not the same behaviour as data, time or timestamp type (added in AVRO-1684).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
