[jira] [Created] (AVRO-3077) Ability of select string deserializing by configuration

["Emilio Jose Mena Cebrian (Jira)" <ji...@apache.org>]

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

 
{code:java}
    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;
            default:
              return CharSequence.class;
            }
          }
{code}
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
(v8.3.4#803005)