Mailing-List: contact dev-help@atlas.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@atlas.apache.org
Date: Thu, 20 Jul 2017 13:31:00 +0000 (UTC)
From: "Sharmadha Sainath (JIRA)" <jira@apache.org>
To: dev@atlas.incubator.apache.org
Message-ID: <JIRA.13088739.1500556318000.292264.1500557460197@Atlassian.JIRA>
In-Reply-To: <JIRA.13088739.1500556318000@Atlassian.JIRA>
References: <JIRA.13088739.1500556318000@Atlassian.JIRA> <JIRA.13088739.1500556318663@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (ATLAS-1970) Export/Import - When
 updateTypeDefinition set to false , new types are not imported
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 20 Jul 2017 13:31:06 -0000


    [ https://issues.apache.org/jira/browse/ATLAS-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16094679#comment-16094679 ] 

Sharmadha Sainath edited comment on ATLAS-1970 at 7/20/17 1:30 PM:
-------------------------------------------------------------------

Added a patch with fix to allow creation of types even when updateTypeDefinition is set to false.

As there can be many types in the exported zip file ( which may / may not be present in the backup cluster ) , it would be a little overhead to check if type is already present and update if present.

Also ,  updateTypeDefinition's default value is true. So , if updateTypeDefinition is set to true or not set at all , Atlas would still go ahead and create/update the types.

Please let me know/re-assign if there is be a better way of fixing this.

Tested the patch with following :
1. updateTypeDefinition set to false
2. updateTypeDefinition set to true
3. updateTypeDefinition is not specified
4. updateTypeDefinition with true/false with other options such as transforms

CC : [~ashutoshm] [~madhan@apache.org]


was (Author: ssainath):
Added a patch with fix to allow creation of types even when updateTypeDefinition is set to false.

As there can be many types in the exported zip file ( which may / may not be present in the backup cluster ) , it would be a little overhead to check if type is already present and update if present.

Also ,  updateTypeDefinition's default value is true. So , if updateTypeDefinition is set to true or not set at all , Atlas would still go ahead and create/update the types.

Please let me know/re-assign if there could be a better way of fixing this.

Tested the patch with following :
1. updateTypeDefinition set to false
2. updateTypeDefinition set to true
3. updateTypeDefinition is not specified
4. updateTypeDefinition with true/false with other options such as transforms


> Export/Import - When updateTypeDefinition set to false , new types are not imported
> -----------------------------------------------------------------------------------
>
>                 Key: ATLAS-1970
>                 URL: https://issues.apache.org/jira/browse/ATLAS-1970
>             Project: Atlas
>          Issue Type: Bug
>          Components:  atlas-core
>    Affects Versions: 0.9-incubating, 0.8.1-incubating
>            Reporter: Sharmadha Sainath
>            Assignee: Sharmadha Sainath
>            Priority: Critical
>         Attachments: ATLAS-1970.patch, ImportFailureDueToUnknownType.txt
>
>
> Import has option "updateTypeDefinition" which is used to update the type definitions in the backup cluster (cluster on which import is done) when the value is set to true. (Default is set to true). When its value is set to false , types in backup cluster are not updated with types present in exported zip file.
> This works fine when , say a type type1 is present in both clusters , an entity of type type1 is exported and imported into backup cluster with updateTypeDefinition is set to false - Import is done successfully and type is not updated.
> When the zip file contains type5 *which is not present in backup cluster* and the when import is fired , import fails with following exception:
> {code}
> {"errorCode":"ATLAS-500-00-001","errorMessage":"org.apache.atlas.exception.AtlasBaseException: Type ENTITY with name type5 does not exist"}
> {code}
> Attached the complete exception stack trace found in backup cluster's application logs. 


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)