[
https://issues.apache.org/jira/browse/AVRO-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504034#comment-17504034
]
Oscar Westra van Holthe - Kind commented on AVRO-2495:
------------------------------------------------------
A (somewhat) dissenting opinion:
# Having the system logical types being handled differently is not a problem;
it just means there's no example to implement your own. This is something we
can improve though.
# Conversion is a different, wider topic: As you state, you want to set a field
using any type that can be converted to the logical type. And then you mention
you want to set date values using strings, which is a difficult enough to
warrant several books written on it. Not that this is wrong, but there are many
caveats (and configuration options) to handle.
# With {{toString()}} you have a valid point. Please contribute your opinion on
the mailing list ("Request for comments: new parsing & formatting interface"),
and add your comments to AVRO-2832. I'm especially interested in your view on
how to select the right conversion for formatting.
# This can be done better, but is really only a problem when using
{{GenericRecord}}/{{GenericData}} (ideal for use in libraries, where you can
handle this in your, uniform way). Using generated code (and {{SpecificData}})
or annotated code (and {{ReflectData}}) is strongly types, and does not have
this problem.
# Having existing logical types with extension points is tricky. It's better
for maintainability to create your own. The stuff you want to reuse is not the
logical type, but the conversions (and they can be subclassed).
So in short, I think the best place to start are points 3 and 5. Point 4 is not
an issue, and points 1 and 2 are good to pick up next.
> Java: LogicalTypes not implemented nicely
> -----------------------------------------
>
> Key: AVRO-2495
> URL: https://issues.apache.org/jira/browse/AVRO-2495
> Project: Apache Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.9.0
> Reporter: Werner Daehn
> Priority: Major
>
> I'd like to use this Jira as a boilerplate for a couple of issues in the
> LogicalType handling. Will split those into individual ones, once it has been
> confirmed I am not completely wrong.
>
> Generally speaking, the LogicalTypes and their backing with a native type is
> quite nice but from a usability point of view there are multiple areas where
> we could do better.
> # Provided LogicalTypes and custom LogicalTypes are handled differently. The
> latter are registered via LogicalTypes.register(), the provided ones are all
> hardcoded.
> # Java <–> Avro conversion is not nice. From a user perspective, I'd like to
> set a record via record.put("timestampmillis_column", LocalDateTime.now());
> So by providing one of many possible value objects like Date, Instant,
> LocalDateTime,... even s proper formatted string. Another example is the
> amount of code you have to write in order to set a Decimal. When all the user
> wants is to say record.put("Quantity", 1.2). see below
> # toString() of a record does not consider LogicalTypes, e.g. a BigDecimal
> is shown as the backing \u0000\u00FF value instead of a human readable format.
> # Where ever a value is used, you have to check if there is a logical type.
> If not use the base type. This can be done better.
> # Lacking extension points. Imagine I want to extend the TimestampMillis
> LogicalType to add my own code. Not possible. First because how the
> LogicalType is created and second because constructors are private.
> Do you agree or am I missing an important point?
>
> {{{{DecimalConversion DECIMAL_CONVERTER = new DecimalConversion();
> }}}}{{{{Schema s = item.getSchema().getField("Quantity").schema();
> }}}}{{{{Decimal l = (Decimal) s.getLogicalType();
> }}}}{{{{BigDecimal d = BigDecimal.valueOf(4.0).setScale(l.getScale());
> }}}}{{{{ByteBuffer value = DECIMAL_CONVERTER.toBytes(d, null, l);
> }}}}{{{{item.put("Quantity", value);}}}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
