[
https://issues.apache.org/jira/browse/HIVE-25126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated HIVE-25126:
----------------------------------
Description:
Remove all references to
NoSuchObjectException/InvalidOperationException/MetaException from the method
signature of RawStore. These Exceptions are generated by Thrift and are used
to communicate error conditions across the wire. They are not designed for use
as part of the underlying stack, yet in Hive, they have been pushed down into
these data access operators.
The RawStore should not have to be this tightly coupled to the transport layer.
Remove all checked Exceptions from RawStore in favor of Hive runtime
exceptions. This is a popular format and is used (and therefore dovetails
nicely) with the underlying database access library DataNucleaus.
All of the logging of un-checked Exceptions, and transforming them into Thrift
exceptions, should happen at the Hive-Thrift bridge ({{HMSHandler}}).
The RawStore is a pretty generic Data Access Object. Given the name "Raw" I
assume that the backing data store could really be anything. With that said, I
would say there are two phases of this:
# Remove Thrift Exception to decouple from Thrift
# Throw relevant Hive Runtime Exceptions to decouple from JDO/DataNucleaus
Item number 2 is required because DataNucleaus throws a lot of unchecked
runtime exceptions. From reading the current {{ObjectStore}} code, it appears
that many of these exceptions are bubbled up to the caller thus tying the
caller to handle different exceptions depending on the data source (though they
only see a {{RawStore}}). The calling code should only have to deal with Hive
exceptions and be hidden from the underlying data storage layer.
was:
Remove all references to
NoSuchObjectException/InvalidOperationException/MetaException from the method
signature of RawStore. These Exceptions are generated by Thrift and are used
to communicate error conditions across the wire. They are not designed for use
as part of the underlying stack, yet in Hive, they have been pushed down into
these data access operators.
The RawStore should not have to be this tightly coupled to the transport layer.
Remove all checked Exceptions from RawStore in favor of Hive runtime
exceptions. This is a popular format and is used (and therefore dovetails
nicely) with the underlying database access library DataNucleaus.
All of the logging of un-checked Exceptions, and transforming them into Thrift
exceptions, should happen at the Hive-Thrift bridge ({{HMSHandler}}).
> Remove Thrift Exceptions From RawStore
> --------------------------------------
>
> Key: HIVE-25126
> URL: https://issues.apache.org/jira/browse/HIVE-25126
> Project: Hive
> Issue Type: Improvement
> Reporter: David Mollitor
> Priority: Major
>
> Remove all references to
> NoSuchObjectException/InvalidOperationException/MetaException from the method
> signature of RawStore. These Exceptions are generated by Thrift and are used
> to communicate error conditions across the wire. They are not designed for
> use as part of the underlying stack, yet in Hive, they have been pushed down
> into these data access operators.
>
> The RawStore should not have to be this tightly coupled to the transport
> layer.
>
> Remove all checked Exceptions from RawStore in favor of Hive runtime
> exceptions. This is a popular format and is used (and therefore dovetails
> nicely) with the underlying database access library DataNucleaus.
> All of the logging of un-checked Exceptions, and transforming them into
> Thrift exceptions, should happen at the Hive-Thrift bridge ({{HMSHandler}}).
>
> The RawStore is a pretty generic Data Access Object. Given the name "Raw" I
> assume that the backing data store could really be anything. With that said,
> I would say there are two phases of this:
>
> # Remove Thrift Exception to decouple from Thrift
> # Throw relevant Hive Runtime Exceptions to decouple from JDO/DataNucleaus
>
> Item number 2 is required because DataNucleaus throws a lot of unchecked
> runtime exceptions. From reading the current {{ObjectStore}} code, it appears
> that many of these exceptions are bubbled up to the caller thus tying the
> caller to handle different exceptions depending on the data source (though
> they only see a {{RawStore}}). The calling code should only have to deal
> with Hive exceptions and be hidden from the underlying data storage layer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
