[
https://issues.apache.org/jira/browse/AVRO-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15331268#comment-15331268
]
Yibing Shi edited comment on AVRO-1847 at 6/15/16 2:01 PM:
-----------------------------------------------------------
# I will add javadoc to those public functions
# I will change the test case names.
# I will correct the help messages for compiler tool. Do you think it worth to
use Apache Commons Options package to process the parameters? (maybe leave it
for a later?)
# The null and "null" thing is a typo. Sorry for this stupid mistake. A null
value will cause problems for SpecificRecordCompiler.
# I will make the parameter in compiler and maven plugin only affects decimal
type, which will minimize the impact of this patch. Thanks for the suggestion!
# For the invariant problem in {{RecordBuilderBase.defaultValue(Field field,
Conversion<?> conversion)}}, I will add a checking to make sure that logical
type is not null before call the {{convertToLogicalType}} method.
# For the convert to logical/raw type methods, I will change it a bit to have
them return null if the original value passed in is null.
# The focus here is the {{convert}} method in GenericDatumWriter. You are
correct about the invariant here. But as [~rdblue] explains below, this used to
be not a problem because the caller within GenericDatumWriter won't pass in any
null pointer. I tends not to add the checking here. One reason is it is good
for performance. The second reason is that a null schema or logical type is
definitely a bad error, and I don't think any children would try to capture or
process it.
was (Author: yibing):
# I will add javadoc to those public functions
# I will change the test case names.
# I will correct the help messages for compiler tool. Do you think it worth to
use Apache Commons Options package to process the parameters? (maybe leave it
for a later?)
# The null and "null" thing is a typo. Sorry for this stupid mistake. A null
value will cause problems for SpecificRecordCompiler.
# I will make the parameter in compiler and maven plugin only affects decimal
type, which will minimize the impact of this patch. Thanks for the suggestion
# The focus here is the {{convert}} method in GenericDatumWriter. You are
correct about the invariant here. But as [~rdblue] explains below, this used to
be not a problem because the caller within GenericDatumWriter won't pass in any
null pointer. I tends not to add the checking here. One reason is it is good
for performance. The second reason is that a null schema or logical type is
definitely a bad error, and I don't think any children would try to capture or
process it.
> 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, AVRO-1847.5.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)
