[
https://issues.apache.org/jira/browse/HCATALOG-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070908#comment-13070908
]
Ashutosh Chauhan commented on HCATALOG-60:
------------------------------------------
Ideally, HCatOutputCommitter should not do anything special in
commitJob/abortJob api as it is doing currently, as this special handling makes
assumption about underlying storage. Deletion as it is currently done should be
a responsibility of underlying baseCommitter not of HCatOutputCommitter. Since,
FileOutputCommitter don't do this, we are doing it here. I will suggest to move
all of this deletion code to RCFileOutputCommitter and keep this one clean
here. This way we need not to worry about location string anymore. Similarly,
in commitJob we should rely on underlying committer to create _SUCCESS file and
not on HCatOutputCommitter. So, here as well we shall move this code to
RCFileOutputCommitter.
> HCatBaseOutputCommitter.abortJob and HCatBaseOutputCommitter.commitJob
> assumes a getLocation() always returns path
> ------------------------------------------------------------------------------------------------------------------
>
> Key: HCATALOG-60
> URL: https://issues.apache.org/jira/browse/HCATALOG-60
> Project: HCatalog
> Issue Type: Bug
> Reporter: Francis Liu
> Assignee: Francis Liu
> Attachments: hcatalog_file.patch
>
>
> Some table sources have no need for paths (ie HBase) and thus
> JobInfo.location may be null. Looks like commitJob was trying to do a test
> before acting on the location but buggy. abortJob does not have such check.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
