Sharmadha Sainath updated ATLAS-1970:
    Comment: was deleted

(was: 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] [~mad...@apache.org])

> 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

Reply via email to