[
https://issues.apache.org/jira/browse/HIVE-25126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346442#comment-17346442
]
David Mollitor edited comment on HIVE-25126 at 5/21/21, 7:17 PM:
-----------------------------------------------------------------
{{MetaException}} is also inconsistent. Some functions that clearly access the
DB do not throw this exception in the signature.
was (Author: belugabehr):
{{MetaException}} is also inconstantly. Some functions that clearly access the
DB do not throw this exception in the signature.
> 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)
