avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emilio Jose Mena Cebrian (Jira)" <j...@apache.org>
Subject [jira] [Created] (AVRO-3077) Ability of select string deserializing by configuration
Date Thu, 11 Mar 2021 10:16:00 GMT
Emilio Jose Mena Cebrian created AVRO-3077:

             Summary: Ability of select string deserializing by configuration
                 Key: AVRO-3077
                 URL: https://issues.apache.org/jira/browse/AVRO-3077
             Project: Apache Avro
          Issue Type: Improvement
          Components: java
    Affects Versions: 1.10.1
            Reporter: Emilio Jose Mena Cebrian

Current Java generator modifies the source schema to add a property to describe the way a
reader decodes a string. (see AVRO-2918)

I think this is a design problem. The way a reader deserializes a string shouldn't modify
the schema (the schema describes the structure of avro message, not the way a reader converts
to a usable form).

On the other hand, a reader might require the strings as a CharSequence because it knows how
to handle them and other as a String.

The only way to do this now is modifying the schema itself in each reader. If you use Avro
with other technologies like Kafka (or confluent) It migth be non-viable.


I think that the way a reader decodes messages should be specified by the reader and It'll
be desirable to specify this using a configuration.


Maybe if a System property (like useCustomCoders feature) or something similar could be added
to modify the default value for String decoding.

Form GenericDatumReader

    protected Class findStringClass(Schema schema) {
            String name = schema.getProp(GenericData.STRING_PROP);
            if (name == null)
              return CharSequence.class;

            switch (GenericData.StringType.valueOf(name)) {
            case String:
              return String.class;
              return CharSequence.class;
Maybe adding a "forced" configuration may help: if reader configures string representation,
use it, if not do it the current way.


And do something similar in SpecificDatumReader







This message was sent by Atlassian Jira

View raw message