[
https://issues.apache.org/jira/browse/PARQUET-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977447#comment-14977447
]
Mark Grey commented on PARQUET-140:
-----------------------------------
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.)
> Allow clients to control the GenericData object that is used to read Avro
> records
> ---------------------------------------------------------------------------------
>
> Key: PARQUET-140
> URL: https://issues.apache.org/jira/browse/PARQUET-140
> Project: Parquet
> Issue Type: Improvement
> Components: parquet-mr
> Reporter: Josh Wills
> Assignee: Josh Wills
> Fix For: 1.6.0
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
