Re: Adding mandatory attribute to an existing entity type
Hi Guys,
Can you please help me with the below issue?
---
Regards,
Sreeni
On 01/10/20, 5:57 PM, "Nallapati, Sreenivasulu"
wrote:
This email is from an external sender.
Hi,
We have an entity type (schema) with name, environment, schema_format as
attributes and we have created few entities for this type.
We want to add new mandatory attribute data_format to schema type. As atlas
is not allowing to add a mandatory attribute, we followed the below steps to
add the mandatory attribute
1. Delete all the entities of this type from atlas.
2. Delete the existing type using curl -negotiate -u user:pwd -X DELETE
-H 'Content-Type: application/json' -H 'Accept: application/json'
"http://localhost:21000/api/atlas/v2/types/typedef/name/schema"; API.
*
org.apache.atlas.repository.graphdb.janus.AtlasJanusGraphManagement.deletePropertyKey(String)
method renamed all the three properties to schema.name_deleted_0,
schema.environment_deleted_0 and schema.schema_format_deleted_0
3. After deleting the model, we posted the updated model with new
mandatory attribute using curl -negotiate -u user:pwd -X POST -H 'Content-Type:
application/json' -H 'Accept: application/json'
"http://localhost:21000/api/atlas/v2/types/typedefs"; -d "@./schema.json"
4. Now graph management has new properties name, environment,
schema_format, data_format and previously renamed properties name_deleted_0,
environment_deleted_0, schema_format_deleted_0
5. When we try to create a new entity with the new model, the entity got
created successfully in the backend store and failing to create the entity in
the search store with the below error (because of mapped-type)
Multiple entries with same key:
schema.name=org.janusgraph.diskstorage.indexing.StandardKeyInformation@55e7c2b4
and
schema.name=org.janusgraph.diskstorage.indexing.StandardKeyInformation@b884972
at
com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:215)
at
com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:209)
at
com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:147)
at
com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:110)
at
com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:393)
at
org.janusgraph.graphdb.database.IndexSerializer$IndexInfoRetriever$1.get(IndexSerializer.java:162)
1. The renamed attributes (schema.name_deleted_0) has a property
“mapped-name” to the schema.type attribute. While building the ImmutableMap,
“mapped-name” of schema.name_deleted_0 is colliding with the schema.name
Have few queries about this functionality.
1. Is there any reason why properties are getting renamed instead of
delete when we delete the model?
2. Is there any configuration setting to tweak this functionality or How
to add a mandatory attribute to the existing model type?
3. Is it ok if we delete the renamed
(m.getPropertyKey('schema.name_deleted_0').remove())properties from graph
management using gremlin console?
Please guide us in the proper direction if we are not doing the right thing.
---
Regards,
Sreeni
Re: Review Request 72923: ATLAS-3968 : - Refactor the typedef API authorization error message with type guid instead type name for call with guid as parameter
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72923/#review221986 --- Ship it! Ship It! - Madhan Neethiraj On Oct. 1, 2020, 2:37 p.m., Nixon Rodrigues wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/72923/ > --- > > (Updated Oct. 1, 2020, 2:37 p.m.) > > > Review request for atlas, Jayendra Parab, Madhan Neethiraj, and Sarath > Subramanian. > > > Bugs: ATLAS-3968 > https://issues.apache.org/jira/browse/ATLAS-3968 > > > Repository: atlas > > > Description > --- > > Bug details - When un-authorised reader reads a type using the guid, the > error message mentions about the type name instead of the guid. > > This patch refactor's the typedef API authorization error message with type > guid instead type name for call with guid as parameter. > > > Diffs > - > > > repository/src/main/java/org/apache/atlas/repository/store/graph/AtlasTypeDefGraphStore.java > 9aa8fbcf5 > > > Diff: https://reviews.apache.org/r/72923/diff/1/ > > > Testing > --- > > Tested typedef of all categorty API with guid and name paramter for > authorized and unauthorized users. > > > Thanks, > > Nixon Rodrigues > >
[jira] [Commented] (ATLAS-3934) Dockerfile should build from local repository rather than pulling code from git
[
https://issues.apache.org/jira/browse/ATLAS-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205854#comment-17205854
]
ASF subversion and git services commented on ATLAS-3934:
Commit 4733b076c943c00d34f1cabad3aa73efa310b10f in atlas's branch
refs/heads/branch-2.0 from Madhan Neethiraj
[ https://gitbox.apache.org/repos/asf?p=atlas.git;h=4733b07 ]
ATLAS-3934: Dockerfile: moved environment variables to .env file - #3
(cherry picked from commit ac573f33c72f5cf9b75b50453ad85dd3abadcb15)
> Dockerfile should build from local repository rather than pulling code from
> git
> ---
>
> Key: ATLAS-3934
> URL: https://issues.apache.org/jira/browse/ATLAS-3934
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Syed Atif Akhtar
>Assignee: Madhan Neethiraj
>Priority: Trivial
> Labels: atlas, build, development_environment, docker
> Fix For: 3.0.0, 2.2.0
>
> Attachments: ATLAS-3934.patch
>
>
> *Expected Behaviour:*
> When a developer wants to test out their changes using the dockerfile in dev
> support, they should be able to create the dockerfile with atlas built and
> mount from a local directory with the changes they have done.
> *Current Behaviour:*
> The dockerfile currently defined in dev-support pulls the source code from
> git instead of building the code that the user has defined
>
> {code:java}
> RUN git clone https://github.com/apache/atlas.git -b master{code}
>
> *Suggestion:*
> Maintain separate dockerfiles for publishing an image of Atlas vs development
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ATLAS-3934) Dockerfile should build from local repository rather than pulling code from git
[
https://issues.apache.org/jira/browse/ATLAS-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205852#comment-17205852
]
ASF subversion and git services commented on ATLAS-3934:
Commit ac573f33c72f5cf9b75b50453ad85dd3abadcb15 in atlas's branch
refs/heads/master from Madhan Neethiraj
[ https://gitbox.apache.org/repos/asf?p=atlas.git;h=ac573f3 ]
ATLAS-3934: Dockerfile: moved environment variables to .env file - #3
> Dockerfile should build from local repository rather than pulling code from
> git
> ---
>
> Key: ATLAS-3934
> URL: https://issues.apache.org/jira/browse/ATLAS-3934
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Syed Atif Akhtar
>Assignee: Madhan Neethiraj
>Priority: Trivial
> Labels: atlas, build, development_environment, docker
> Fix For: 3.0.0, 2.2.0
>
> Attachments: ATLAS-3934.patch
>
>
> *Expected Behaviour:*
> When a developer wants to test out their changes using the dockerfile in dev
> support, they should be able to create the dockerfile with atlas built and
> mount from a local directory with the changes they have done.
> *Current Behaviour:*
> The dockerfile currently defined in dev-support pulls the source code from
> git instead of building the code that the user has defined
>
> {code:java}
> RUN git clone https://github.com/apache/atlas.git -b master{code}
>
> *Suggestion:*
> Maintain separate dockerfiles for publishing an image of Atlas vs development
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Review Request 72915: ATLAS-3934: Dockerfile: moved environment variables to .env file - #3
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72915/#review221985 --- Ship it! Ship It! - Sarath Subramanian On Sept. 29, 2020, 4:07 p.m., Madhan Neethiraj wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/72915/ > --- > > (Updated Sept. 29, 2020, 4:07 p.m.) > > > Review request for atlas, Ashutosh Mestry, Jayendra Parab, Sarath > Subramanian, and Sidharth Mishra. > > > Bugs: ATLAS-3934 > https://issues.apache.org/jira/browse/ATLAS-3934 > > > Repository: atlas > > > Description > --- > > Moved environment variable from Dockerfiles to .env file, which helps avoid > changing Dockerfiles to build with different profiles/branches. > > > Diffs > - > > dev-support/atlas-docker/.env PRE-CREATION > dev-support/atlas-docker/Dockerfile.atlas b90a1ca03 > dev-support/atlas-docker/Dockerfile.atlas-base b7c86abbb > dev-support/atlas-docker/Dockerfile.atlas-build bc27e9fd2 > dev-support/atlas-docker/README.md 9e56fa1b6 > dev-support/atlas-docker/docker-compose.atlas-base.yml 81c421ae6 > dev-support/atlas-docker/docker-compose.atlas-build.yml c72b7d1a5 > dev-support/atlas-docker/docker-compose.atlas.yml ccb1b7297 > dev-support/atlas-docker/scripts/atlas-build.sh eafe4bdad > > > Diff: https://reviews.apache.org/r/72915/diff/1/ > > > Testing > --- > > - built and run Atlas in Docker containers built with docker and > docker-compose commands > > > Thanks, > > Madhan Neethiraj > >
Re: Review Request 72920: ATLAS-3965:Relationships with null values are missing in entity relationshipAttributes
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/72920/#review221982
---
Ship it!
This seems to be fine:
MyClass aClass = null;
if (aClass instanceof MyClass) {
assertTrue(true);
}
- Ashutosh Mestry
On Sept. 30, 2020, 10:53 p.m., Deep Singh wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72920/
> ---
>
> (Updated Sept. 30, 2020, 10:53 p.m.)
>
>
> Review request for atlas, Ashutosh Mestry, madhan, Madhan Neethiraj, and
> Sarath Subramanian.
>
>
> Bugs: ATLAS-3965
> https://issues.apache.org/jira/browse/ATLAS-3965
>
>
> Repository: atlas
>
>
> Description
> ---
>
> In the get call, while reading the entity, we map entity's
> relationshipAttributes by relationship attributes defined in entityTypeDef.
> At this stage we ignore all null valued attributes, therefore all undefined
> attributes with Single cardinality gets ignored. However, attributes with Set
> or List cardinality are not ignored as they are not null by default but empty
> Arrays.
>
> While mapping relationshipAttributes from entityTypeDef to response-entity,
> we should either ignore empty arrays as well or not ignore anything. In this
> Patch I have followed the second aproach which is not to ignore any thing.
>
>
> Diffs
> -
>
>
> repository/src/main/java/org/apache/atlas/repository/store/graph/v2/EntityGraphRetriever.java
> 00146b106
>
>
> Diff: https://reviews.apache.org/r/72920/diff/1/
>
>
> Testing
> ---
>
> Testing is done manually by importing Kafka topic.
> PreCommit Build Test has also passed.
> https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/44//
>
>
> Thanks,
>
> Deep Singh
>
>
[jira] [Commented] (ATLAS-3966) Newer value for a property in application configuration is not loaded
[ https://issues.apache.org/jira/browse/ATLAS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205678#comment-17205678 ] Deep Singh commented on ATLAS-3966: --- Patch Attached PreCpmmit Build Test passed https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/46// Review board link https://reviews.apache.org/r/72921/ > Newer value for a property in application configuration is not loaded > -- > > Key: ATLAS-3966 > URL: https://issues.apache.org/jira/browse/ATLAS-3966 > Project: Atlas > Issue Type: Bug > Components: atlas-intg >Reporter: Deep Singh >Assignee: Deep Singh >Priority: Major > Attachments: > 0003-ATLAS-3966-Newer-value-for-atlas.metadata.namespace-.patch > > > If a property is defined multiple times with different values in the > application configuration file, while loading the proper, the oldest value > is read. Technically this is correct behavior. However many times, instead of > updating the value of a particular property, its convenient to just append > the property again with a new value in the configuration file. > This ask is specifically for a property called "atlas.metadata.namespace" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3966) Newer value for a property in application configuration is not loaded
[ https://issues.apache.org/jira/browse/ATLAS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deep Singh updated ATLAS-3966: -- Attachment: 0003-ATLAS-3966-Newer-value-for-atlas.metadata.namespace-.patch > Newer value for a property in application configuration is not loaded > -- > > Key: ATLAS-3966 > URL: https://issues.apache.org/jira/browse/ATLAS-3966 > Project: Atlas > Issue Type: Bug > Components: atlas-intg >Reporter: Deep Singh >Assignee: Deep Singh >Priority: Major > Attachments: > 0003-ATLAS-3966-Newer-value-for-atlas.metadata.namespace-.patch > > > If a property is defined multiple times with different values in the > application configuration file, while loading the proper, the oldest value > is read. Technically this is correct behavior. However many times, instead of > updating the value of a particular property, its convenient to just append > the property again with a new value in the configuration file. > This ask is specifically for a property called "atlas.metadata.namespace" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ATLAS-3953) JSON Files from Export API with "?" char for string with special chars
[ https://issues.apache.org/jira/browse/ATLAS-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosh Mestry resolved ATLAS-3953. Resolution: Fixed > JSON Files from Export API with "?" char for string with special chars > --- > > Key: ATLAS-3953 > URL: https://issues.apache.org/jira/browse/ATLAS-3953 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Affects Versions: 2.1.0 > Environment: Apache Atlas 2.1.0 embedded HBASE and SOLR >Reporter: Carlos Alberto Rocha Cardoso >Assignee: Ashutosh Mestry >Priority: Major > Attachments: 9fdc3ad0-46c2-430a-89c4-4a751d31c064.json, > ATLAS-3953-Export-ZipSink-Specify-character-endcodin.patch, > Asset_Imported.PNG, AtlasServer.PNG, > a5c148bf-5ab6-4c49-853e-855842102128.json, atlas_export.zip, path.zip > > > The Export API returns a ZIP file with some JSON files describing Atlas > Entities and TypeDefs. > I am having an issue where some special chars in JSON are being replaced by > "?" chars. > An Entity name like "Distribuição" was exported in JSON file like > "Distribui??o". The special chars "çã" was replaced for the "??" chars. > I tried to change the exported JSON file encoding and the request header for > Export API but without success. > After analyzing the Atlas source code, especially the *splitAndWriteBytes* > method of the > *[ZipSink|https://github.com/apache/atlas/blob/cc601d7371fae1dbc16b55d1ca84f06b745700dc/repository/src/main/java/org/apache/atlas/repository/impexp/ZipSink.java] > class*, I thought if maybe the problem is because the *s.getBytes()* is > returning the JSON string to be written to ZIP with another encoding than > *UTF-8*, and maybe set the encode like *s.getBytes(StandardCharsets.UTF_8)* > could be a solution. > It's my first contact with the Atlas source code, and I'm not a JAVA > programmer, so it's only a guess. > I saw that it's possible to set the default to encode to the platform or JVM, > but how they said in this below discussion, perhaps this doesn't work > properly in all situations. > [https://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3953) JSON Files from Export API with "?" char for string with special chars
[ https://issues.apache.org/jira/browse/ATLAS-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205649#comment-17205649 ] ASF subversion and git services commented on ATLAS-3953: Commit 31b8bdb404978e46c5061a6a8423ed8fbb6d3893 in atlas's branch refs/heads/branch-2.0 from Ashutosh Mestry [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=31b8bdb ] ATLAS-3953: Export: ZipSink: Specify character endcoding when writing to ZIP file. Change-Id: I2e3a2bad79f5cf4c91328ed9f64a454ded2acbf3 > JSON Files from Export API with "?" char for string with special chars > --- > > Key: ATLAS-3953 > URL: https://issues.apache.org/jira/browse/ATLAS-3953 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Affects Versions: 2.1.0 > Environment: Apache Atlas 2.1.0 embedded HBASE and SOLR >Reporter: Carlos Alberto Rocha Cardoso >Assignee: Ashutosh Mestry >Priority: Major > Attachments: 9fdc3ad0-46c2-430a-89c4-4a751d31c064.json, > ATLAS-3953-Export-ZipSink-Specify-character-endcodin.patch, > Asset_Imported.PNG, AtlasServer.PNG, > a5c148bf-5ab6-4c49-853e-855842102128.json, atlas_export.zip, path.zip > > > The Export API returns a ZIP file with some JSON files describing Atlas > Entities and TypeDefs. > I am having an issue where some special chars in JSON are being replaced by > "?" chars. > An Entity name like "Distribuição" was exported in JSON file like > "Distribui??o". The special chars "çã" was replaced for the "??" chars. > I tried to change the exported JSON file encoding and the request header for > Export API but without success. > After analyzing the Atlas source code, especially the *splitAndWriteBytes* > method of the > *[ZipSink|https://github.com/apache/atlas/blob/cc601d7371fae1dbc16b55d1ca84f06b745700dc/repository/src/main/java/org/apache/atlas/repository/impexp/ZipSink.java] > class*, I thought if maybe the problem is because the *s.getBytes()* is > returning the JSON string to be written to ZIP with another encoding than > *UTF-8*, and maybe set the encode like *s.getBytes(StandardCharsets.UTF_8)* > could be a solution. > It's my first contact with the Atlas source code, and I'm not a JAVA > programmer, so it's only a guess. > I saw that it's possible to set the default to encode to the platform or JVM, > but how they said in this below discussion, perhaps this doesn't work > properly in all situations. > [https://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3953) JSON Files from Export API with "?" char for string with special chars
[ https://issues.apache.org/jira/browse/ATLAS-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205640#comment-17205640 ] ASF subversion and git services commented on ATLAS-3953: Commit 9a605b6671b1719eebce04605f100e34c8f5afb0 in atlas's branch refs/heads/master from Ashutosh Mestry [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=9a605b6 ] ATLAS-3953: Export: ZipSink: Specify character endcoding when writing to ZIP file. Change-Id: I2e3a2bad79f5cf4c91328ed9f64a454ded2acbf3 > JSON Files from Export API with "?" char for string with special chars > --- > > Key: ATLAS-3953 > URL: https://issues.apache.org/jira/browse/ATLAS-3953 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Affects Versions: 2.1.0 > Environment: Apache Atlas 2.1.0 embedded HBASE and SOLR >Reporter: Carlos Alberto Rocha Cardoso >Assignee: Ashutosh Mestry >Priority: Major > Attachments: 9fdc3ad0-46c2-430a-89c4-4a751d31c064.json, > ATLAS-3953-Export-ZipSink-Specify-character-endcodin.patch, > Asset_Imported.PNG, AtlasServer.PNG, > a5c148bf-5ab6-4c49-853e-855842102128.json, atlas_export.zip, path.zip > > > The Export API returns a ZIP file with some JSON files describing Atlas > Entities and TypeDefs. > I am having an issue where some special chars in JSON are being replaced by > "?" chars. > An Entity name like "Distribuição" was exported in JSON file like > "Distribui??o". The special chars "çã" was replaced for the "??" chars. > I tried to change the exported JSON file encoding and the request header for > Export API but without success. > After analyzing the Atlas source code, especially the *splitAndWriteBytes* > method of the > *[ZipSink|https://github.com/apache/atlas/blob/cc601d7371fae1dbc16b55d1ca84f06b745700dc/repository/src/main/java/org/apache/atlas/repository/impexp/ZipSink.java] > class*, I thought if maybe the problem is because the *s.getBytes()* is > returning the JSON string to be written to ZIP with another encoding than > *UTF-8*, and maybe set the encode like *s.getBytes(StandardCharsets.UTF_8)* > could be a solution. > It's my first contact with the Atlas source code, and I'm not a JAVA > programmer, so it's only a guess. > I saw that it's possible to set the default to encode to the platform or JVM, > but how they said in this below discussion, perhaps this doesn't work > properly in all situations. > [https://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding] -- This message was sent by Atlassian Jira (v8.3.4#803005)
Review Request 72923: ATLAS-3968 : - Refactor the typedef API authorization error message with type guid instead type name for call with guid as parameter
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72923/ --- Review request for atlas, Jayendra Parab, Madhan Neethiraj, and Sarath Subramanian. Bugs: ATLAS-3968 https://issues.apache.org/jira/browse/ATLAS-3968 Repository: atlas Description --- Bug details - When un-authorised reader reads a type using the guid, the error message mentions about the type name instead of the guid. This patch refactor's the typedef API authorization error message with type guid instead type name for call with guid as parameter. Diffs - repository/src/main/java/org/apache/atlas/repository/store/graph/AtlasTypeDefGraphStore.java 9aa8fbcf5 Diff: https://reviews.apache.org/r/72923/diff/1/ Testing --- Tested typedef of all categorty API with guid and name paramter for authorized and unauthorized users. Thanks, Nixon Rodrigues
[jira] [Assigned] (ATLAS-3968) When un-authorised reader reads a type using the guid, the error message mentions about the type name instead of the guid
[
https://issues.apache.org/jira/browse/ATLAS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nixon Rodrigues reassigned ATLAS-3968:
--
Assignee: Nixon Rodrigues
> When un-authorised reader reads a type using the guid, the error message
> mentions about the type name instead of the guid
> -
>
> Key: ATLAS-3968
> URL: https://issues.apache.org/jira/browse/ATLAS-3968
> Project: Atlas
> Issue Type: Bug
>Reporter: Dharshana M Krishnamoorthy
>Assignee: Nixon Rodrigues
>Priority: Major
>
> On firing a request for /api/atlas/v2/types/businessmetadatadef/guid/
> as an unauthorised user, the following error message is displayed
> {code:java}
> {
> u'errorCode': u'ATLAS-403-00-001',
> u'errorMessage': u'hrt_20 is not authorized to perform read type bm_123'
> }
> {code}
> Since we are firing the request using guid, it will be better to mention the
> guid instead of the type name
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ATLAS-3968) When un-authorised reader reads a type using the guid, the error message mentions about the type name instead of the guid
Dharshana M Krishnamoorthy created ATLAS-3968:
-
Summary: When un-authorised reader reads a type using the guid,
the error message mentions about the type name instead of the guid
Key: ATLAS-3968
URL: https://issues.apache.org/jira/browse/ATLAS-3968
Project: Atlas
Issue Type: Bug
Reporter: Dharshana M Krishnamoorthy
On firing a request for /api/atlas/v2/types/businessmetadatadef/guid/ as
an unauthorised user, the following error message is displayed
{code:java}
{
u'errorCode': u'ATLAS-403-00-001',
u'errorMessage': u'hrt_20 is not authorized to perform read type bm_123'
}
{code}
Since we are firing the request using guid, it will be better to mention the
guid instead of the type name
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ATLAS-3967) On creating a type with a type_name of a different category, 409 conflict error is thrown
Dharshana M Krishnamoorthy created ATLAS-3967:
-
Summary: On creating a type with a type_name of a different
category, 409 conflict error is thrown
Key: ATLAS-3967
URL: https://issues.apache.org/jira/browse/ATLAS-3967
Project: Atlas
Issue Type: Bug
Components: atlas-core
Reporter: Dharshana M Krishnamoorthy
On creating a classification with a name same as business_metadata type, 409 is
thrown
Existing business metadata:
{code:java|title=business_metadata details}
{"category":"BUSINESS_METADATA","guid":"-416986733842","createdBy":"hrt_qa","updatedBy":"hrt_qa","createTime":1601466038742,"updateTime":1601466038742,"version":1,"name":"read_auth_business_metadata_WXuUg","description":"bm
description","typeVersion":"1.0","attributeDefs":[]}
{code}
create a classification with name "*read_auth_business_metadata_WXuUg*"
this gives a conflict error
Create request payload: to endpoint
*api/atlas/v2/types/typedefs?type=classification*
{code}
{"classificationDefs":[\{"name":"read_auth_business_metadata_WXuUg","description":"","superTypes":[],"attributeDefs":[]}],"entityDefs":[],"enumDefs":[],"structDefs":[]}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Adding mandatory attribute to an existing entity type
Hi,
We have an entity type (schema) with name, environment, schema_format as
attributes and we have created few entities for this type.
We want to add new mandatory attribute data_format to schema type. As atlas is
not allowing to add a mandatory attribute, we followed the below steps to add
the mandatory attribute
1. Delete all the entities of this type from atlas.
2. Delete the existing type using curl -negotiate -u user:pwd -X DELETE -H
'Content-Type: application/json' -H 'Accept: application/json'
"http://localhost:21000/api/atlas/v2/types/typedef/name/schema"; API.
*
org.apache.atlas.repository.graphdb.janus.AtlasJanusGraphManagement.deletePropertyKey(String)
method renamed all the three properties to schema.name_deleted_0,
schema.environment_deleted_0 and schema.schema_format_deleted_0
3. After deleting the model, we posted the updated model with new mandatory
attribute using curl -negotiate -u user:pwd -X POST -H 'Content-Type:
application/json' -H 'Accept: application/json'
"http://localhost:21000/api/atlas/v2/types/typedefs"; -d "@./schema.json"
4. Now graph management has new properties name, environment, schema_format,
data_format and previously renamed properties name_deleted_0,
environment_deleted_0, schema_format_deleted_0
5. When we try to create a new entity with the new model, the entity got
created successfully in the backend store and failing to create the entity in
the search store with the below error (because of mapped-type)
Multiple entries with same key:
schema.name=org.janusgraph.diskstorage.indexing.StandardKeyInformation@55e7c2b4
and
schema.name=org.janusgraph.diskstorage.indexing.StandardKeyInformation@b884972
at
com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:215)
at
com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:209)
at
com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:147)
at
com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:110)
at
com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:393)
at
org.janusgraph.graphdb.database.IndexSerializer$IndexInfoRetriever$1.get(IndexSerializer.java:162)
1. The renamed attributes (schema.name_deleted_0) has a property
“mapped-name” to the schema.type attribute. While building the ImmutableMap,
“mapped-name” of schema.name_deleted_0 is colliding with the schema.name
Have few queries about this functionality.
1. Is there any reason why properties are getting renamed instead of delete
when we delete the model?
2. Is there any configuration setting to tweak this functionality or How to
add a mandatory attribute to the existing model type?
3. Is it ok if we delete the renamed
(m.getPropertyKey('schema.name_deleted_0').remove())properties from graph
management using gremlin console?
Please guide us in the proper direction if we are not doing the right thing.
---
Regards,
Sreeni
