[ 
https://issues.apache.org/jira/browse/HIVE-24933?focusedWorklogId=796037&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-796037
 ]

ASF GitHub Bot logged work on HIVE-24933:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 28/Jul/22 10:55
            Start Date: 28/Jul/22 10:55
    Worklog Time Spent: 10m 
      Work Description: jhungund commented on PR #3435:
URL: https://github.com/apache/hive/pull/3435#issuecomment-1197987231

   Hi Francis,
   Thank you for taking a look at this change.
   Below are my replies to your comments (starting with **[JH]**) below
   
   > Can you add an analysis? Like the reason for the bug and how you are 
fixing it?
   > 
   **[JH]**I have added a detailed comment about the root cause analysis. 
Please take a look.
   
   > From the changes, I can infer that the access is "deferred", moved from 
occurring semantic analysis "load table" time, to later when the task actually 
runs and does the copy.
   **[JH]** Yes, this is right.
   > 
   > But what necessitates needing this? Did some state change between the two 
points?
   **[JH]** Please check the detailed comment added earlier.
   > 
   > Is this the significant change?
   > 
   > > table = ImportSemanticAnalyzer.tableIfExists(tblDesc, hive);
   > > if (table == null) {
   > > table = ImportSemanticAnalyzer.createNewTableMetadataObject(tblDesc, 
true);
   > > }
   > 
   **[JH]** Yes, the access and the subsequent check:
   if (AcidUtils.isTransactionalTable(table)) {
   returns different results at task creation time and task execution time.
   
   > So at deferred time, the copy/move/etc is only done if the table exists?
   > 
   > Just wondering if you can pass runnable/callable/function from 
ImportSemanticAnaylzer, so to keep all that current logic in the same place and 
not moved to another file. Then the DeferredWorkHelperImpl just needs to 
execute it, and logic can be removed from there.
   
   **[JH]** The current logic of moving code in deferred implementation 
simplifies the callers which only need to set the deferred implementation 
class. This keeps the logic at the same place as the execution. Hence, it looks 
OK to me.
   Do let me know, if it looks ok. If not, I can try to change it as per your 
comment.
   
   Thanks,
   Janardhan




Issue Time Tracking
-------------------

    Worklog Id:     (was: 796037)
    Time Spent: 2h 20m  (was: 2h 10m)

> Replication fails for transactional tables having same name as dropped 
> non-transactional table
> ----------------------------------------------------------------------------------------------
>
>                 Key: HIVE-24933
>                 URL: https://issues.apache.org/jira/browse/HIVE-24933
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Pratyush Madhukar
>            Assignee: Pratyush Madhukar
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to