[
https://issues.apache.org/jira/browse/HIVE-25126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346433#comment-17346433
]
David Mollitor commented on HIVE-25126:
---------------------------------------
As I work through this, I see that in {{RawStore}}
{code:java}
/**
*....
* @throws MetaException general database exception
*/
{code}
That's not actually true. A "general database exception" is almost never
caught in {{ObjectStore}} and thrown as a {{MetaException}}. All "general
database exceptions" are {{RuntimeExceptions}} generated by DataNucleaus and
bubble-up (and never handled)
> 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
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
