Allow clients to control the GenericData object that is used to read Avro records

[asfimport]

Right now, Parquet always uses the default SpecificData instance (retrieved by SpecificData.get()) to lookup the schemas for SpecificRecord subclasses. Unfortunately, if the definition of the SpecificRecord subclass is not available to the classloader used in SpecificData.get(), we will fail to find the definition of the SpecificRecord subclass and will fall back to returning a GenericRecord, which will cause a ClassCastException in any client code that is expecting an instance of the SpecificRecord subclass.

We can fix this limitation by allowing the client code to specify how to construct a custom instance of SpecificData (or any other subclass of GenericData) for Parquet to use, including instances of SpecificData that use alternative classloaders.

Reporter: Josh Wills / @jwills
Assignee: Josh Wills / @jwills

_{Note: This issue was originally created as PARQUET-140. Please see the migration documentation for further details.}

[asfimport]

Josh Wills / @jwills:
Created pull req: https://github.com/apache/incubator-parquet-mr/pull/90

[asfimport]

Thomas White / @tomwhite:
I committed this. Thanks Josh!

[asfimport]

Mark Grey:
I am wondering could address the converse case as well? (I have a SpecificData class on the classpath but want to coerce to GenericData.Record instances everywhere possible, including nested records.)

[asfimport]

Ryan Blue / @rdblue:
[~DeaconDesperado], you are correct. This allows you to use generic classes instead of specific by specifying GenericData instead of SpecificData or ReflectData.