Re: Review Request 59881: ATLAS-1863 :- Set default value for primitive types attributes in entity based on attributeDef in Typedef

2017-06-15 Thread Ruchi Solani

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59881/
---

(Updated June 16, 2017, 5:34 a.m.)


Review request for atlas, Apoorv Naik, Madhan Neethiraj, Nixon Rodrigues, and 
Sarath Subramanian.


Changes
---

This patch includes changes to address review comments given by Madhan and Unit 
test to validate whether defaultValue is set to entity attribute when 
attributedef has  default Value property.


Bugs: ATLAS-1863
https://issues.apache.org/jira/browse/ATLAS-1863


Repository: atlas


Description
---

While creating entity if attribute value are not set explicitly for primitive 
type which are optional, then default value should be set from attributedef.


Diffs (updated)
-

  intg/src/main/java/org/apache/atlas/model/typedef/AtlasStructDef.java aee4907 
  intg/src/main/java/org/apache/atlas/type/AtlasArrayType.java 2d386f1 
  intg/src/main/java/org/apache/atlas/type/AtlasEntityType.java 6516d48 
  intg/src/main/java/org/apache/atlas/type/AtlasMapType.java 385a9ae 
  intg/src/main/java/org/apache/atlas/type/AtlasStructType.java 0eeaf9c 
  intg/src/main/java/org/apache/atlas/type/AtlasType.java 28d0a07 
  intg/src/test/java/org/apache/atlas/TestUtilsV2.java 2a6ea92 
  intg/src/test/java/org/apache/atlas/type/TestAtlasArrayType.java e882473 
  
repository/src/main/java/org/apache/atlas/repository/store/graph/v1/AtlasStructDefStoreV1.java
 1c6cfc7 
  
repository/src/main/java/org/apache/atlas/repository/store/graph/v1/EntityGraphMapper.java
 80cd1ee 
  
repository/src/test/java/org/apache/atlas/repository/store/graph/v1/AtlasEntityStoreV1Test.java
 44067b9 


Diff: https://reviews.apache.org/r/59881/diff/3/

Changes: https://reviews.apache.org/r/59881/diff/2-3/


Testing
---

1. created Type using API with defaultValue attribute, and tested its entity 
creation with default value being set in entity attribute.
2. Tested on different primitive types attributes.
3. Ran Unit tests using mvn clean install
 Two unit test failing:
   
HardDeleteHandlerV1Test>AtlasDeleteHandlerV1Test.testDisconnectUnidirectionalArrayReferenceFromStructAndTraitTypes:617
 » AtlasBase
  
SoftDeleteHandlerV1Test>AtlasDeleteHandlerV1Test.testDisconnectUnidirectionalArrayReferenceFromStructAndTraitTypes:617
 » AtlasBase


Thanks,

Ruchi Solani



Re: Review Request 59769: [ATLAS-1856]: Relationship instance API Java & REST implementation

2017-06-15 Thread Sarath Subramanian

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59769/
---

(Updated June 15, 2017, 5:42 p.m.)


Review request for atlas and Madhan Neethiraj.


Bugs: ATLAS-1856
https://issues.apache.org/jira/browse/ATLAS-1856


Repository: atlas


Description
---

Based on the relationDef implementation in ATLAS-1852. Implement instance API 
and REST for entity relationships. This patch is not complete.
work in progress


Diffs
-

  
authorization/src/main/java/org/apache/atlas/authorize/AtlasResourceTypes.java 
deccf843 
  
authorization/src/main/java/org/apache/atlas/authorize/simple/AtlasAuthorizationUtils.java
 e907bf5e 
  
authorization/src/main/java/org/apache/atlas/authorize/simple/PolicyParser.java 
7ef49e66 
  intg/src/main/java/org/apache/atlas/model/instance/AtlasRelationship.java 
PRE-CREATION 
  
intg/src/main/java/org/apache/atlas/model/typedef/AtlasRelationshipEndDef.java 
000d747b 
  intg/src/main/java/org/apache/atlas/type/AtlasTypeRegistry.java aebd4d1a 
  
repository/src/main/java/org/apache/atlas/repository/store/graph/AtlasRelationshipStore.java
 PRE-CREATION 
  
repository/src/main/java/org/apache/atlas/repository/store/graph/v1/AtlasRelationshipStoreV1.java
 PRE-CREATION 
  
repository/src/main/java/org/apache/atlas/repository/typestore/GraphBackedTypeStore.java
 7a064b60 
  repository/src/test/java/org/apache/atlas/TestModules.java 095af417 
  webapp/src/main/java/org/apache/atlas/web/rest/RelationshipREST.java 
PRE-CREATION 


Diff: https://reviews.apache.org/r/59769/diff/2/


Testing
---

Tested using POSTMAN.


Thanks,

Sarath Subramanian



[jira] [Updated] (ATLAS-1856) Relationship instance API Java & REST implementation

2017-06-15 Thread Sarath Subramanian (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sarath Subramanian updated ATLAS-1856:
--
Attachment: curl_create_new_relationDef
curl_create_new_relationInstance
ATLAS-1856.2.patch

> Relationship instance API Java & REST implementation
> 
>
> Key: ATLAS-1856
> URL: https://issues.apache.org/jira/browse/ATLAS-1856
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: trunk, 0.9-incubating
>Reporter: Sarath Subramanian
>Assignee: Sarath Subramanian
> Attachments: ATLAS-1856.2.patch, curl_create_new_relationDef, 
> curl_create_new_relationInstance
>
>
> Based on the relationDef implementation in ATLAS-1852. Implement instance API 
> and REST for entity relationships



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


[jira] [Updated] (ATLAS-1856) Relationship instance API Java & REST implementation

2017-06-15 Thread Sarath Subramanian (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sarath Subramanian updated ATLAS-1856:
--
Attachment: (was: curl_create_new_relationDef)

> Relationship instance API Java & REST implementation
> 
>
> Key: ATLAS-1856
> URL: https://issues.apache.org/jira/browse/ATLAS-1856
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: trunk, 0.9-incubating
>Reporter: Sarath Subramanian
>Assignee: Sarath Subramanian
>
> Based on the relationDef implementation in ATLAS-1852. Implement instance API 
> and REST for entity relationships



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


[jira] [Updated] (ATLAS-1856) Relationship instance API Java & REST implementation

2017-06-15 Thread Sarath Subramanian (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sarath Subramanian updated ATLAS-1856:
--
Attachment: (was: curl_create_new_relationInstance)

> Relationship instance API Java & REST implementation
> 
>
> Key: ATLAS-1856
> URL: https://issues.apache.org/jira/browse/ATLAS-1856
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: trunk, 0.9-incubating
>Reporter: Sarath Subramanian
>Assignee: Sarath Subramanian
>
> Based on the relationDef implementation in ATLAS-1852. Implement instance API 
> and REST for entity relationships



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


[jira] [Updated] (ATLAS-1856) Relationship instance API Java & REST implementation

2017-06-15 Thread Sarath Subramanian (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sarath Subramanian updated ATLAS-1856:
--
Attachment: (was: ATLAS-1856.1.patch)

> Relationship instance API Java & REST implementation
> 
>
> Key: ATLAS-1856
> URL: https://issues.apache.org/jira/browse/ATLAS-1856
> Project: Atlas
>  Issue Type: New Feature
>  Components:  atlas-core
>Affects Versions: trunk, 0.9-incubating
>Reporter: Sarath Subramanian
>Assignee: Sarath Subramanian
>
> Based on the relationDef implementation in ATLAS-1852. Implement instance API 
> and REST for entity relationships



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


Re: Review Request 60066: ATLAS-1865 - Cannot create trait/term in Chinese

2017-06-15 Thread Sarath Subramanian

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60066/#review178033
---




repository/src/main/java/org/apache/atlas/repository/store/graph/v1/AtlasClassificationDefStoreV1.java
Line 46 (original), 46 (patched)


TRAIT_NAME_REGEX may grow in size each time we decide to add a new 
language. We need to find the locale of the string and validate it against 
supported locales for Atlas.


- Sarath Subramanian


On June 14, 2017, 3:18 a.m., qinglin xia wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60066/
> ---
> 
> (Updated June 14, 2017, 3:18 a.m.)
> 
> 
> Review request for atlas.
> 
> 
> Bugs: ATLAS-1865
> https://issues.apache.org/jira/browse/ATLAS-1865
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> Fix ATLAS-1865 (https://issues.apache.org/jira/browse/ATLAS-1865), Atlas 0.9 
> can not create trait/term in Chinese
> 
> 
> Diffs
> -
> 
>   
> repository/src/main/java/org/apache/atlas/repository/store/graph/v1/AtlasClassificationDefStoreV1.java
>  89445048 
> 
> 
> Diff: https://reviews.apache.org/r/60066/diff/2/
> 
> 
> Testing
> ---
> 
> Create Term in Chinese
> Create Trait in Chinese
> 
> 
> Thanks,
> 
> qinglin xia
> 
>



[jira] [Commented] (ATLAS-1875) Gremlin id is no longer returned for vertices in gremlin query

2017-06-15 Thread Graham Wallis (JIRA)

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

Graham Wallis commented on ATLAS-1875:
--

Hi Christian,
The removal of the Vertex id from the result was accidental. So we should add 
it back in, presumably we should add this to 0.8 and 0.9.



> Gremlin id is no longer returned for vertices in gremlin query
> --
>
> Key: ATLAS-1875
> URL: https://issues.apache.org/jira/browse/ATLAS-1875
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: trunk, 0.8-incubating
>Reporter: Christian R
>  Labels: dsl, gremlin
>
> Hi, 
> while investigating a move from atlas 0.7 to 0.8 (HDP 2.5 to HDP2.6) our 
> tests fail on gremlin queries. It turns out that the returned entities in a 
> gremlin search in 0.8 does not include the 'id' attribute. 
> I've built commit a0bd93945cd45457bbf34a8cb819d4fa4ba72964 (0.8-rc1) on linux 
> using berkely and elasticearch to test with. 
> The query 
> :21000/api/atlas/discovery/search/gremlin?g.V.has('__type.name', 
> 'Infrastructure').collect()
> on our 0.7 cluster gives
> {code:json}
> {
> __type.name: "Infrastructure",
> __type.category: "CLASS",
> __type: "typeSystem",
> id: "16640"
> }{code}
> while the same query on my 0.8-rc1 installation gives 
> {code:javascript}
> {
> __type.name: "Infrastructure",
> __version: "1",
> __type.category: "CLASS",
> __type.version: "1.0",
> __modificationTimestamp: "1497448424134",
> __type: "typeSystem",
> __type.options: "null",
> __type.description: "Infrastructure",
> __guid: "77d07283-7622-4305-9c0c-09ac5aee86c8",
> __timestamp: "1497448424134"
> }
> {code}
> Certainly more information, but id is missing. 
> The very poor DSL performance (see  ATLAS-1868) and a need for advanced 
> queries led us to base our queries on gremlin. This has worked very well so 
> far. We include both edges and nodes in the result set and use the inVertex, 
> outVertex and label info on the edges to rebuild our tree on the client side.
> I also see that gremlin has disappeared from version two of the API. Since 
> addE and addV lets you insert into the graph I can see how exposing a full 
> gremlin endpoint might not be wanted. 
> As an example of the queries we run that I haven't been able to express in 
> the DSL is 
> {noformat}
> query = g.V.has('__guid','').copySplit(
>   _().out('track'), 
>   _().as('x')
>   .out('functions', 'component')
>   .loop('x'){true}{true}
>   .copySplit(
>   _(),
>   _().in('part_of'),
>   _().outE('functions', 
> 'component'),
>   _().inE('part_of')
>   )
>   .exhaustMerge.dedup
>   )
>   .exhaustMerge
> .collect()
> {noformat}
> this might not be a normal usecase. 
> edit to add: 
> I looked at GraphBackedDiscoveryService.java and notice that:
> 0.7:
> {code:java}
> else if (r instanceof TitanVertex) {
> Iterable ps = ((TitanVertex) 
> r).getProperties();
> for (TitanProperty tP : ps) {
> String pName = tP.getPropertyKey().getName();
> Object pValue = ((TitanVertex) r).getProperty(pName);
> if (pValue != null) {
> oRow.put(pName, pValue.toString());
> }
> }
> {code}
> Vs 0.8 code: 
> {code:java}
> else if (value instanceof AtlasVertex) {
> AtlasVertex vertex = (AtlasVertex)value;
> for (String key : vertex.getPropertyKeys()) {
> Object propertyValue = 
> GraphHelper.getProperty(vertex,  key);
> if (propertyValue != null) {
> oRow.put(key, propertyValue.toString());
> }
> }
> {code}
> look very similar. 
> However, 0.8 handles id in edges explicitly while the 0.7 doesn’t treat edges 
> explicitly at all.
> {code:java}
> else if(value instanceof AtlasEdge) {
> AtlasEdge edge = (AtlasEdge) value;
> oRow.put("id", edge.getId().toString());
> oRow.put("label", edge.getLabel());
> oRow.put("inVertex", 
> edge.getInVertex().getId().toString());
> oRow.put("outVertex", 
> edge.getOutVertex().getId().toString());
> for (String propertyKey : edge.

[jira] [Updated] (ATLAS-1863) Set default value for primitive types attributes in entity based on attributeDef in Typedef

2017-06-15 Thread Nixon Rodrigues (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nixon Rodrigues updated ATLAS-1863:
---
Attachment: ATLAS-1863.3.patch

> Set default value for primitive types attributes in entity based on 
> attributeDef in Typedef
> ---
>
> Key: ATLAS-1863
> URL: https://issues.apache.org/jira/browse/ATLAS-1863
> Project: Atlas
>  Issue Type: Improvement
>  Components: atlas-intg
>Reporter: Nixon Rodrigues
>Assignee: Ruchi Solani
>Priority: Critical
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-1863.2.patch, ATLAS-1863.3.patch, ATLAS-1863.patch
>
>
> While creating entity if attribute value are not set explicitly for primitive 
> type which are optional, then default value should be set from attributedef.
> eg of typedef attributeDef
> {code}
> "attributeDefs": [{
>   "name": "sourceCode",
>   "typeName": "string",
>   "isOptional": true,
>   "cardinality": "SINGLE",
>   "valuesMinCount": 0,
>   "valuesMaxCount": 1,
>   "isUnique": false,
>   "isIndexable": true,
>   "defaultValue": "xyz"
>   }
> {code}



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


[jira] [Assigned] (ATLAS-1876) Import/Export : AtlasSchemaViolationException during Import of entity associated to a tag with tag attribute value of datatype float

2017-06-15 Thread Ashutosh Mestry (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashutosh Mestry reassigned ATLAS-1876:
--

Assignee: Ashutosh Mestry

> Import/Export : AtlasSchemaViolationException during Import of entity 
> associated to a tag with tag attribute value of datatype float
> 
>
> Key: ATLAS-1876
> URL: https://issues.apache.org/jira/browse/ATLAS-1876
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: 0.9-incubating
>Reporter: Sharmadha Sainath
>Assignee: Ashutosh Mestry
> Attachments: AtlasSchemaViolationException_ExportImport.txt
>
>
> 1.In cluster1, created a tag float_tag with attribute float_max of datatype 
> float.
> 2. In the same cluster , created table table1 and associated the tag 
> float_tag to table1 , with attribute value for float_max as 3.4028235e+38 
> (maximum value for float).
> 3.Creation and tag association are successful.
> 4.Created table1.zip  by using Export API 
> 5. Using Import API , tried to import table1.zip to cluster2. Import failed 
> with 
> {code}
> {"errorCode":"ATLAS-500-00-001","errorMessage":"org.apache.atlas.exception.AtlasBaseException:
>  org.apache.atlas.repository.graphdb.AtlasSchemaViolationException: 
> com.thinkaurelius.titan.core.SchemaViolationException: Value [3.4028235E38] 
> is not an instance of the expected data type for property key 
> [float_tag.float_max] and cannot be converted. Expected: class 
> java.lang.Float, found: class java.lang.Double"}
> {code}
> Attached the error stack trace found in cluster2 application logs.
> This exception is seen only when the value for float attribute is given as 
> 3.4028235e+38 . Other values like 0 , 2.5 , 1.4e+10 etc., are accepted and 
> import is done successfully.



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


[jira] [Commented] (ATLAS-1875) Gremlin id is no longer returned for vertices in gremlin query

2017-06-15 Thread Graham Wallis (JIRA)

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

Graham Wallis commented on ATLAS-1875:
--

Hi Christian

The id appears to have been removed when the move was made Titan classes to 
Atlas classes (i.e. the abstraction layer). 

I've contacted the committer to check whether deliberate or accidental. Will 
post answer here.

> Gremlin id is no longer returned for vertices in gremlin query
> --
>
> Key: ATLAS-1875
> URL: https://issues.apache.org/jira/browse/ATLAS-1875
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: trunk, 0.8-incubating
>Reporter: Christian R
>  Labels: dsl, gremlin
>
> Hi, 
> while investigating a move from atlas 0.7 to 0.8 (HDP 2.5 to HDP2.6) our 
> tests fail on gremlin queries. It turns out that the returned entities in a 
> gremlin search in 0.8 does not include the 'id' attribute. 
> I've built commit a0bd93945cd45457bbf34a8cb819d4fa4ba72964 (0.8-rc1) on linux 
> using berkely and elasticearch to test with. 
> The query 
> :21000/api/atlas/discovery/search/gremlin?g.V.has('__type.name', 
> 'Infrastructure').collect()
> on our 0.7 cluster gives
> {code:json}
> {
> __type.name: "Infrastructure",
> __type.category: "CLASS",
> __type: "typeSystem",
> id: "16640"
> }{code}
> while the same query on my 0.8-rc1 installation gives 
> {code:javascript}
> {
> __type.name: "Infrastructure",
> __version: "1",
> __type.category: "CLASS",
> __type.version: "1.0",
> __modificationTimestamp: "1497448424134",
> __type: "typeSystem",
> __type.options: "null",
> __type.description: "Infrastructure",
> __guid: "77d07283-7622-4305-9c0c-09ac5aee86c8",
> __timestamp: "1497448424134"
> }
> {code}
> Certainly more information, but id is missing. 
> The very poor DSL performance (see  ATLAS-1868) and a need for advanced 
> queries led us to base our queries on gremlin. This has worked very well so 
> far. We include both edges and nodes in the result set and use the inVertex, 
> outVertex and label info on the edges to rebuild our tree on the client side.
> I also see that gremlin has disappeared from version two of the API. Since 
> addE and addV lets you insert into the graph I can see how exposing a full 
> gremlin endpoint might not be wanted. 
> As an example of the queries we run that I haven't been able to express in 
> the DSL is 
> {noformat}
> query = g.V.has('__guid','').copySplit(
>   _().out('track'), 
>   _().as('x')
>   .out('functions', 'component')
>   .loop('x'){true}{true}
>   .copySplit(
>   _(),
>   _().in('part_of'),
>   _().outE('functions', 
> 'component'),
>   _().inE('part_of')
>   )
>   .exhaustMerge.dedup
>   )
>   .exhaustMerge
> .collect()
> {noformat}
> this might not be a normal usecase. 
> edit to add: 
> I looked at GraphBackedDiscoveryService.java and notice that:
> 0.7:
> {code:java}
> else if (r instanceof TitanVertex) {
> Iterable ps = ((TitanVertex) 
> r).getProperties();
> for (TitanProperty tP : ps) {
> String pName = tP.getPropertyKey().getName();
> Object pValue = ((TitanVertex) r).getProperty(pName);
> if (pValue != null) {
> oRow.put(pName, pValue.toString());
> }
> }
> {code}
> Vs 0.8 code: 
> {code:java}
> else if (value instanceof AtlasVertex) {
> AtlasVertex vertex = (AtlasVertex)value;
> for (String key : vertex.getPropertyKeys()) {
> Object propertyValue = 
> GraphHelper.getProperty(vertex,  key);
> if (propertyValue != null) {
> oRow.put(key, propertyValue.toString());
> }
> }
> {code}
> look very similar. 
> However, 0.8 handles id in edges explicitly while the 0.7 doesn’t treat edges 
> explicitly at all.
> {code:java}
> else if(value instanceof AtlasEdge) {
> AtlasEdge edge = (AtlasEdge) value;
> oRow.put("id", edge.getId().toString());
> oRow.put("label", edge.getLabel());
> oRow.put("inVertex", 
> edge.getInVertex().getId().toString());
> oRow.put("outVertex", 
> edge.getOutVer

[jira] [Assigned] (ATLAS-1877) UI: In Lineage for Process entity process icon is not showing.

2017-06-15 Thread Keval Bhatt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keval Bhatt reassigned ATLAS-1877:
--

Assignee: (was: Keval Bhatt)

> UI: In Lineage for Process entity process icon is not showing.
> --
>
> Key: ATLAS-1877
> URL: https://issues.apache.org/jira/browse/ATLAS-1877
> Project: Atlas
>  Issue Type: Bug
>Reporter: Keval Bhatt
> Attachments: wrong_process_icon.png
>
>
> UI should check Process entity in all parent superType, right know its 
> checking for only 1 level
> Step to reproduce :
> # Run quickstart
> # Create entity of type Process and while creating process select time_dim 
> (Table entity) as a input and output.
> # Now got to sales_fact_monthly_mv entity and you will see new output (Please 
> find attached screenshot )



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


[jira] [Updated] (ATLAS-1877) UI: In Lineage for Process entity process icon is not showing.

2017-06-15 Thread Keval Bhatt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keval Bhatt updated ATLAS-1877:
---
Attachment: wrong_process_icon.png

> UI: In Lineage for Process entity process icon is not showing.
> --
>
> Key: ATLAS-1877
> URL: https://issues.apache.org/jira/browse/ATLAS-1877
> Project: Atlas
>  Issue Type: Bug
>Reporter: Keval Bhatt
>Assignee: Keval Bhatt
> Attachments: wrong_process_icon.png
>
>
> UI should check Process entity in all parent superType, right know its 
> checking for only 1 level
> Step to reproduce :
> # Run quickstart
> # Create entity of type Process and while creating process select time_dim 
> (Table entity) as a input and output.
> # Now got to sales_fact_monthly_mv entity and you will see new output (Please 
> find attached screenshot )



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


[jira] [Updated] (ATLAS-1877) UI: In Lineage for Process entity process icon is not showing.

2017-06-15 Thread Keval Bhatt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keval Bhatt updated ATLAS-1877:
---
Description: 
UI should check Process entity in all parent superType, right know its checking 
for only 1 level

Step to reproduce :
# Run quickstart
# Create entity of type Process and while creating process select time_dim 
(Table entity) as a input and output.
# Now got to sales_fact_monthly_mv entity and you will see new output (Please 
find attached screenshot )

  was:
UI should check Process entity in all parent superType, right know its checking 
for only 1 level

Step to reproduce :
# Run quickstart
# Create entity of type Process and while creating process select time_dim 
(Table entity) as a input and output.
# Now got to time_dim entity and you will see new output (Please find attached 
screenshot )


> UI: In Lineage for Process entity process icon is not showing.
> --
>
> Key: ATLAS-1877
> URL: https://issues.apache.org/jira/browse/ATLAS-1877
> Project: Atlas
>  Issue Type: Bug
>Reporter: Keval Bhatt
>Assignee: Keval Bhatt
>
> UI should check Process entity in all parent superType, right know its 
> checking for only 1 level
> Step to reproduce :
> # Run quickstart
> # Create entity of type Process and while creating process select time_dim 
> (Table entity) as a input and output.
> # Now got to sales_fact_monthly_mv entity and you will see new output (Please 
> find attached screenshot )



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


[jira] [Updated] (ATLAS-1877) UI: In Lineage for Process entity process icon is not showing.

2017-06-15 Thread Keval Bhatt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keval Bhatt updated ATLAS-1877:
---
Description: 
UI should check Process entity in all parent superType, right know its checking 
for only 1 level

Step to reproduce :
# Run quickstart
# Create entity of type Process and while creating process select time_dim 
(Table entity) as a input and output.
# Now got to time_dim entity and you will see new output (Please find attached 
screenshot )

  was:UI should check Process entity in all parent superType, right know its 
checking for only 1 level


> UI: In Lineage for Process entity process icon is not showing.
> --
>
> Key: ATLAS-1877
> URL: https://issues.apache.org/jira/browse/ATLAS-1877
> Project: Atlas
>  Issue Type: Bug
>Reporter: Keval Bhatt
>Assignee: Keval Bhatt
>
> UI should check Process entity in all parent superType, right know its 
> checking for only 1 level
> Step to reproduce :
> # Run quickstart
> # Create entity of type Process and while creating process select time_dim 
> (Table entity) as a input and output.
> # Now got to time_dim entity and you will see new output (Please find 
> attached screenshot )



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


[jira] [Comment Edited] (ATLAS-1781) Atlas UI cannot show lineage pic when inputs and outputs of lineage are the same entity

2017-06-15 Thread Keval Bhatt (JIRA)

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

Keval Bhatt edited comment on ATLAS-1781 at 6/15/17 12:57 PM:
--

[~xiaqinglin] for Icon issue I created another jira ATLAS-1877


was (Author: kevalbhatt18):
[~xiaqinglin] For Icon issue I created another jira ATLAS-1877

> Atlas UI cannot show lineage pic when inputs and outputs of lineage are the 
> same entity
> ---
>
> Key: ATLAS-1781
> URL: https://issues.apache.org/jira/browse/ATLAS-1781
> Project: Atlas
>  Issue Type: Bug
>  Components: atlas-webui
>Affects Versions: trunk, 0.7-incubating, 0.8-incubating, 0.7.1-incubating, 
> 0.9-incubating
>Reporter: qinglin,xia
>Assignee: Xinzhi,Luo
>  Labels: atlas
> Fix For: 0.9-incubating
>
> Attachments: 0001-fix-ATLAS-1781.patch, 
> 0001-fix-not-working-with-more-than-2-nodes-with-ATLAS-17.patch, 
> after_test-wrong_op.png, browser_error.png, expected.png, fixed.png, Linage 
> fix not working with more than 2 nodes with ATLAS-1781.png, 
> Lineage_Create_Successfully_when_inputs_outputs_different.png, 
> Lineage_keep_loading.png, Process_Type_Not_Blue.png, 
> Starting_point_is_Impact_than_icon&arrow_colour_is_wrong(KEVAL_2_review).jpg
>
>
> I was working with the lineage for hbase, when I added a column family in a 
> hbase table, I want to create a lineage for the table to show there is a 
> change within the table schema, yet when I create a process using the atlas 
> api, I found that the process entity is successfully created, but the lineage 
> is not shown on the atlas web page.
> Steps to Reproduce this issue is: 
> 1. build up an entity extends the DataSet Type
> 2. build up a lineage Process
> 3. set the process input and output to the same entity
> The code is like:
> Referenceable table1 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, input_table_name);
> Referenceable table2 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, output_table_name);
> HBaseProcess process = new HBaseProcess("process");
> process.setInput(table1.getId());
> process.setoutput(table2.getId());
> here I set the input_table_name and output_table_name the same string name, 
> when I set them different values, the lineage pic can be shown for table1 and 
> table2 successfully
> Screenshots are:
> 1) The lineage pic keep loading on the atlas UI 
> 2) The error log reported by the browser console
> 3) The lineage pic showed successfully when set the inputs and outputs of the 
> lineage to different entities.  



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


[jira] [Commented] (ATLAS-1781) Atlas UI cannot show lineage pic when inputs and outputs of lineage are the same entity

2017-06-15 Thread Keval Bhatt (JIRA)

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

Keval Bhatt commented on ATLAS-1781:


[~xiaqinglin] For Icon issue I created another jira ATLAS-1877

> Atlas UI cannot show lineage pic when inputs and outputs of lineage are the 
> same entity
> ---
>
> Key: ATLAS-1781
> URL: https://issues.apache.org/jira/browse/ATLAS-1781
> Project: Atlas
>  Issue Type: Bug
>  Components: atlas-webui
>Affects Versions: trunk, 0.7-incubating, 0.8-incubating, 0.7.1-incubating, 
> 0.9-incubating
>Reporter: qinglin,xia
>Assignee: Xinzhi,Luo
>  Labels: atlas
> Fix For: 0.9-incubating
>
> Attachments: 0001-fix-ATLAS-1781.patch, 
> 0001-fix-not-working-with-more-than-2-nodes-with-ATLAS-17.patch, 
> after_test-wrong_op.png, browser_error.png, expected.png, fixed.png, Linage 
> fix not working with more than 2 nodes with ATLAS-1781.png, 
> Lineage_Create_Successfully_when_inputs_outputs_different.png, 
> Lineage_keep_loading.png, Process_Type_Not_Blue.png, 
> Starting_point_is_Impact_than_icon&arrow_colour_is_wrong(KEVAL_2_review).jpg
>
>
> I was working with the lineage for hbase, when I added a column family in a 
> hbase table, I want to create a lineage for the table to show there is a 
> change within the table schema, yet when I create a process using the atlas 
> api, I found that the process entity is successfully created, but the lineage 
> is not shown on the atlas web page.
> Steps to Reproduce this issue is: 
> 1. build up an entity extends the DataSet Type
> 2. build up a lineage Process
> 3. set the process input and output to the same entity
> The code is like:
> Referenceable table1 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, input_table_name);
> Referenceable table2 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, output_table_name);
> HBaseProcess process = new HBaseProcess("process");
> process.setInput(table1.getId());
> process.setoutput(table2.getId());
> here I set the input_table_name and output_table_name the same string name, 
> when I set them different values, the lineage pic can be shown for table1 and 
> table2 successfully
> Screenshots are:
> 1) The lineage pic keep loading on the atlas UI 
> 2) The error log reported by the browser console
> 3) The lineage pic showed successfully when set the inputs and outputs of the 
> lineage to different entities.  



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


[jira] [Created] (ATLAS-1877) UI: In Lineage for Process entity process icon is not showing.

2017-06-15 Thread Keval Bhatt (JIRA)
Keval Bhatt created ATLAS-1877:
--

 Summary: UI: In Lineage for Process entity process icon is not 
showing.
 Key: ATLAS-1877
 URL: https://issues.apache.org/jira/browse/ATLAS-1877
 Project: Atlas
  Issue Type: Bug
Reporter: Keval Bhatt
Assignee: Keval Bhatt


UI should check Process entity in all parent superType, right know its checking 
for only 1 level



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


[jira] [Updated] (ATLAS-1876) Import/Export : AtlasSchemaViolationException during Import of entity associated to a tag with tag attribute value of datatype float

2017-06-15 Thread Sharmadha Sainath (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sharmadha Sainath updated ATLAS-1876:
-
Description: 
1.In cluster1, created a tag float_tag with attribute float_max of datatype 
float.
2. In the same cluster , created table table1 and associated the tag float_tag 
to table1 , with attribute value for float_max as 3.4028235e+38 (maximum value 
for float).
3.Creation and tag association are successful.
4.Created table1.zip  by using Export API 
5. Using Import API , tried to import table1.zip to cluster2. Import failed 
with 
{code}
{"errorCode":"ATLAS-500-00-001","errorMessage":"org.apache.atlas.exception.AtlasBaseException:
 org.apache.atlas.repository.graphdb.AtlasSchemaViolationException: 
com.thinkaurelius.titan.core.SchemaViolationException: Value [3.4028235E38] is 
not an instance of the expected data type for property key 
[float_tag.float_max] and cannot be converted. Expected: class java.lang.Float, 
found: class java.lang.Double"}
{code}

Attached the error stack trace found in cluster2 application logs.

This exception is seen only when the value for float attribute is given as 
3.4028235e+38 . Other values like 0 , 2.5 , 1.4e+10 etc., are accepted and 
import is done successfully.

  was:
1.In cluster1, created a tag float_tag with attribute float_max of datatype 
float.
2. In the same cluster , created table table1 and associated the tag float_tag 
to table1 , with attribute value for float_max as 3.4028235e+38 (maximum value 
for float).
3.Creation and tag association are successful.
4.Created table1.zip  by using Export API 
5. Using Import API , tried to import table1.zip to cluster2. Import failed 
with 
{code}
{"errorCode":"ATLAS-500-00-001","errorMessage":"org.apache.atlas.exception.AtlasBaseException:
 org.apache.atlas.repository.graphdb.AtlasSchemaViolationException: 
com.thinkaurelius.titan.core.SchemaViolationException: Value [3.4028235E38] is 
not an instance of the expected data type for property key 
[float_tag.float_max] and cannot be converted. Expected: class java.lang.Float, 
found: class java.lang.Double"}
{code}

Attached the error stack trace found in cluster2 application logs.


> Import/Export : AtlasSchemaViolationException during Import of entity 
> associated to a tag with tag attribute value of datatype float
> 
>
> Key: ATLAS-1876
> URL: https://issues.apache.org/jira/browse/ATLAS-1876
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: 0.9-incubating
>Reporter: Sharmadha Sainath
> Attachments: AtlasSchemaViolationException_ExportImport.txt
>
>
> 1.In cluster1, created a tag float_tag with attribute float_max of datatype 
> float.
> 2. In the same cluster , created table table1 and associated the tag 
> float_tag to table1 , with attribute value for float_max as 3.4028235e+38 
> (maximum value for float).
> 3.Creation and tag association are successful.
> 4.Created table1.zip  by using Export API 
> 5. Using Import API , tried to import table1.zip to cluster2. Import failed 
> with 
> {code}
> {"errorCode":"ATLAS-500-00-001","errorMessage":"org.apache.atlas.exception.AtlasBaseException:
>  org.apache.atlas.repository.graphdb.AtlasSchemaViolationException: 
> com.thinkaurelius.titan.core.SchemaViolationException: Value [3.4028235E38] 
> is not an instance of the expected data type for property key 
> [float_tag.float_max] and cannot be converted. Expected: class 
> java.lang.Float, found: class java.lang.Double"}
> {code}
> Attached the error stack trace found in cluster2 application logs.
> This exception is seen only when the value for float attribute is given as 
> 3.4028235e+38 . Other values like 0 , 2.5 , 1.4e+10 etc., are accepted and 
> import is done successfully.



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


[jira] [Created] (ATLAS-1876) Import/Export : AtlasSchemaViolationException during Import of entity associated to a tag with tag attribute value of datatype float

2017-06-15 Thread Sharmadha Sainath (JIRA)
Sharmadha Sainath created ATLAS-1876:


 Summary: Import/Export : AtlasSchemaViolationException during 
Import of entity associated to a tag with tag attribute value of datatype float
 Key: ATLAS-1876
 URL: https://issues.apache.org/jira/browse/ATLAS-1876
 Project: Atlas
  Issue Type: Bug
  Components:  atlas-core
Affects Versions: 0.9-incubating
Reporter: Sharmadha Sainath
 Attachments: AtlasSchemaViolationException_ExportImport.txt

1.In cluster1, created a tag float_tag with attribute float_max of datatype 
float.
2. In the same cluster , created table table1 and associated the tag float_tag 
to table1 , with attribute value for float_max as 3.4028235e+38 (maximum value 
for float).
3.Creation and tag association are successful.
4.Created table1.zip  by using Export API 
5. Using Import API , tried to import table1.zip to cluster2. Import failed 
with 
{code}
{"errorCode":"ATLAS-500-00-001","errorMessage":"org.apache.atlas.exception.AtlasBaseException:
 org.apache.atlas.repository.graphdb.AtlasSchemaViolationException: 
com.thinkaurelius.titan.core.SchemaViolationException: Value [3.4028235E38] is 
not an instance of the expected data type for property key 
[float_tag.float_max] and cannot be converted. Expected: class java.lang.Float, 
found: class java.lang.Double"}
{code}

Attached the error stack trace found in cluster2 application logs.



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


[jira] [Comment Edited] (ATLAS-1875) Gremlin id is no longer returned for vertices in gremlin query

2017-06-15 Thread Christian R (JIRA)

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

Christian R edited comment on ATLAS-1875 at 6/15/17 11:30 AM:
--

Hi Graham, 

The big uncertainty for me is if the omission of id was deliberate or not from 
the comitters' side. 

You can checkout any revision by {{git checkout }} . You can get the 
sha1's for the relevant commits from the [releases tab 
|https://github.com/apache/incubator-atlas/releases] on github. 

 {{git checkout e48bd3558a81e0d4c104f315e623ed0f6200d169}} gives you 0.7-rc3. 
 {{git checkout a0bd93945cd45457bbf34a8cb819d4fa4ba72964}} gives you 0.8-rc1. 

Then a "mvn clean package" will build it for you. 

I have added 

{code:java}
oRow.put("id", vertex.getId().toString());
{code}

to GraphBackedDiscoveryService line 227 on revision 0.8-rc1 and rebuilt with 
tests executing. In my local build {{id}} is indeed returned. Most of our 
integration tests against 0.7 then work against 0.8. (Some behaviour in POSTing 
to entities/ changed, we had to move to PUT on entities)





was (Author: christianmr):
Hi Graham, 

The big uncertainty for me is if the omission of id was deliberate or not from 
the comitters' side. 

You can checkout any revision by {{git checkout }} . You can get the 
sha1's for the relevant commits from the [releases tab 
|https://github.com/apache/incubator-atlas/releases] on github. 

 {{git checkout e48bd3558a81e0d4c104f315e623ed0f6200d169}} gives you 0.7-rc3. 
 {{git checkout a0bd93945cd45457bbf34a8cb819d4fa4ba72964}} gives you 0.8-rc1. 

Then a "mvn clean package" will build it for you. 

I have added 

{code:java}
oRow.put("id", vertex.getId().toString());
{code}

to GraphBackedDiscoveryService line 227 on revision 0.8-rc1 and rebuilt with 
tests executing. With my local build id is returned works fine. Most of our 
integration tests against 0.7 then work against 0.8. (Some behaviour in POSTing 
to entities/ changed, we had to move to PUT on entities)




> Gremlin id is no longer returned for vertices in gremlin query
> --
>
> Key: ATLAS-1875
> URL: https://issues.apache.org/jira/browse/ATLAS-1875
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: trunk, 0.8-incubating
>Reporter: Christian R
>  Labels: dsl, gremlin
>
> Hi, 
> while investigating a move from atlas 0.7 to 0.8 (HDP 2.5 to HDP2.6) our 
> tests fail on gremlin queries. It turns out that the returned entities in a 
> gremlin search in 0.8 does not include the 'id' attribute. 
> I've built commit a0bd93945cd45457bbf34a8cb819d4fa4ba72964 (0.8-rc1) on linux 
> using berkely and elasticearch to test with. 
> The query 
> :21000/api/atlas/discovery/search/gremlin?g.V.has('__type.name', 
> 'Infrastructure').collect()
> on our 0.7 cluster gives
> {code:json}
> {
> __type.name: "Infrastructure",
> __type.category: "CLASS",
> __type: "typeSystem",
> id: "16640"
> }{code}
> while the same query on my 0.8-rc1 installation gives 
> {code:javascript}
> {
> __type.name: "Infrastructure",
> __version: "1",
> __type.category: "CLASS",
> __type.version: "1.0",
> __modificationTimestamp: "1497448424134",
> __type: "typeSystem",
> __type.options: "null",
> __type.description: "Infrastructure",
> __guid: "77d07283-7622-4305-9c0c-09ac5aee86c8",
> __timestamp: "1497448424134"
> }
> {code}
> Certainly more information, but id is missing. 
> The very poor DSL performance (see  ATLAS-1868) and a need for advanced 
> queries led us to base our queries on gremlin. This has worked very well so 
> far. We include both edges and nodes in the result set and use the inVertex, 
> outVertex and label info on the edges to rebuild our tree on the client side.
> I also see that gremlin has disappeared from version two of the API. Since 
> addE and addV lets you insert into the graph I can see how exposing a full 
> gremlin endpoint might not be wanted. 
> As an example of the queries we run that I haven't been able to express in 
> the DSL is 
> {noformat}
> query = g.V.has('__guid','').copySplit(
>   _().out('track'), 
>   _().as('x')
>   .out('functions', 'component')
>   .loop('x'){true}{true}
>   .copySplit(
>   _(),
>   _().in('part_of'),
>   _().outE('functions', 
> 'component'),
>   _().inE('part_of')
>   )
>   .exhaustMerge.dedup
>   )
>   .ex

[jira] [Comment Edited] (ATLAS-1875) Gremlin id is no longer returned for vertices in gremlin query

2017-06-15 Thread Christian R (JIRA)

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

Christian R edited comment on ATLAS-1875 at 6/15/17 11:27 AM:
--

Hi Graham, 

The big uncertainty for me is if the omission of id was deliberate or not from 
the comitters' side. 

You can checkout any revision by {{git checkout }} . You can get the 
sha1's for the relevant commits from the [releases tab 
|https://github.com/apache/incubator-atlas/releases] on github. 

 {{git checkout e48bd3558a81e0d4c104f315e623ed0f6200d169}} gives you 0.7-rc3. 
 {{git checkout a0bd93945cd45457bbf34a8cb819d4fa4ba72964}} gives you 0.8-rc1. 

Then a "mvn clean package" will build it for you. 

I have added 

{code:java}
oRow.put("id", vertex.getId().toString());
{code}

to GraphBackedDiscoveryService line 227 on revision 0.8-rc1 and rebuilt with 
tests executing. With my local build id is returned works fine. Most of our 
integration tests against 0.7 then work against 0.8. (Some behaviour in POSTing 
to entities/ changed, we had to move to PUT on entities)





was (Author: christianmr):
Hi Graham, 

you can checkout any revision by {{git checkout }} . You can get the 
sha1's for the relevant commits from the [releases tab 
|https://github.com/apache/incubator-atlas/releases] on github. 

 {{git checkout e48bd3558a81e0d4c104f315e623ed0f6200d169}} gives you 0.7-rc3. 
 {{git checkout a0bd93945cd45457bbf34a8cb819d4fa4ba72964}} gives you 0.8-rc1. 

Then a "mvn clean package" will build it for you. 

I have added 

{code:java}
oRow.put("id", vertex.getId().toString());
{code}

to GraphBackedDiscoveryService line 227 on revision 0.8-rc1 and rebuilt with 
tests executing. With my local build id is returned works fine. Most of our 
integration tests against 0.7 then work against 0.8. (Some behaviour in POSTing 
to entities/ changed, we had to move to PUT on entities)


The big uncertainty for me is if the omission of id was deliberate or not from 
the comitters' side. 

> Gremlin id is no longer returned for vertices in gremlin query
> --
>
> Key: ATLAS-1875
> URL: https://issues.apache.org/jira/browse/ATLAS-1875
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: trunk, 0.8-incubating
>Reporter: Christian R
>  Labels: dsl, gremlin
>
> Hi, 
> while investigating a move from atlas 0.7 to 0.8 (HDP 2.5 to HDP2.6) our 
> tests fail on gremlin queries. It turns out that the returned entities in a 
> gremlin search in 0.8 does not include the 'id' attribute. 
> I've built commit a0bd93945cd45457bbf34a8cb819d4fa4ba72964 (0.8-rc1) on linux 
> using berkely and elasticearch to test with. 
> The query 
> :21000/api/atlas/discovery/search/gremlin?g.V.has('__type.name', 
> 'Infrastructure').collect()
> on our 0.7 cluster gives
> {code:json}
> {
> __type.name: "Infrastructure",
> __type.category: "CLASS",
> __type: "typeSystem",
> id: "16640"
> }{code}
> while the same query on my 0.8-rc1 installation gives 
> {code:javascript}
> {
> __type.name: "Infrastructure",
> __version: "1",
> __type.category: "CLASS",
> __type.version: "1.0",
> __modificationTimestamp: "1497448424134",
> __type: "typeSystem",
> __type.options: "null",
> __type.description: "Infrastructure",
> __guid: "77d07283-7622-4305-9c0c-09ac5aee86c8",
> __timestamp: "1497448424134"
> }
> {code}
> Certainly more information, but id is missing. 
> The very poor DSL performance (see  ATLAS-1868) and a need for advanced 
> queries led us to base our queries on gremlin. This has worked very well so 
> far. We include both edges and nodes in the result set and use the inVertex, 
> outVertex and label info on the edges to rebuild our tree on the client side.
> I also see that gremlin has disappeared from version two of the API. Since 
> addE and addV lets you insert into the graph I can see how exposing a full 
> gremlin endpoint might not be wanted. 
> As an example of the queries we run that I haven't been able to express in 
> the DSL is 
> {noformat}
> query = g.V.has('__guid','').copySplit(
>   _().out('track'), 
>   _().as('x')
>   .out('functions', 'component')
>   .loop('x'){true}{true}
>   .copySplit(
>   _(),
>   _().in('part_of'),
>   _().outE('functions', 
> 'component'),
>   _().inE('part_of')
>   )
>   .exhaustMerge.dedup
>   )
>   .ex

[jira] [Commented] (ATLAS-1875) Gremlin id is no longer returned for vertices in gremlin query

2017-06-15 Thread Christian R (JIRA)

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

Christian R commented on ATLAS-1875:


Hi Graham, 

you can checkout any revision by {{git checkout }} . You can get the 
sha1's for the relevant commits from the [releases tab 
|https://github.com/apache/incubator-atlas/releases] on github. 

 {{git checkout e48bd3558a81e0d4c104f315e623ed0f6200d169}} gives you 0.7-rc3. 
 {{git checkout a0bd93945cd45457bbf34a8cb819d4fa4ba72964}} gives you 0.8-rc1. 

Then a "mvn clean package" will build it for you. 

I have added 

{code:java}
oRow.put("id", vertex.getId().toString());
{code}

to GraphBackedDiscoveryService line 227 on revision 0.8-rc1 and rebuilt with 
tests executing. With my local build id is returned works fine. Most of our 
integration tests against 0.7 then work against 0.8. (Some behaviour in POSTing 
to entities/ changed, we had to move to PUT on entities)


The big uncertainty for me is if the omission of id was deliberate or not from 
the comitters' side. 

> Gremlin id is no longer returned for vertices in gremlin query
> --
>
> Key: ATLAS-1875
> URL: https://issues.apache.org/jira/browse/ATLAS-1875
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: trunk, 0.8-incubating
>Reporter: Christian R
>  Labels: dsl, gremlin
>
> Hi, 
> while investigating a move from atlas 0.7 to 0.8 (HDP 2.5 to HDP2.6) our 
> tests fail on gremlin queries. It turns out that the returned entities in a 
> gremlin search in 0.8 does not include the 'id' attribute. 
> I've built commit a0bd93945cd45457bbf34a8cb819d4fa4ba72964 (0.8-rc1) on linux 
> using berkely and elasticearch to test with. 
> The query 
> :21000/api/atlas/discovery/search/gremlin?g.V.has('__type.name', 
> 'Infrastructure').collect()
> on our 0.7 cluster gives
> {code:json}
> {
> __type.name: "Infrastructure",
> __type.category: "CLASS",
> __type: "typeSystem",
> id: "16640"
> }{code}
> while the same query on my 0.8-rc1 installation gives 
> {code:javascript}
> {
> __type.name: "Infrastructure",
> __version: "1",
> __type.category: "CLASS",
> __type.version: "1.0",
> __modificationTimestamp: "1497448424134",
> __type: "typeSystem",
> __type.options: "null",
> __type.description: "Infrastructure",
> __guid: "77d07283-7622-4305-9c0c-09ac5aee86c8",
> __timestamp: "1497448424134"
> }
> {code}
> Certainly more information, but id is missing. 
> The very poor DSL performance (see  ATLAS-1868) and a need for advanced 
> queries led us to base our queries on gremlin. This has worked very well so 
> far. We include both edges and nodes in the result set and use the inVertex, 
> outVertex and label info on the edges to rebuild our tree on the client side.
> I also see that gremlin has disappeared from version two of the API. Since 
> addE and addV lets you insert into the graph I can see how exposing a full 
> gremlin endpoint might not be wanted. 
> As an example of the queries we run that I haven't been able to express in 
> the DSL is 
> {noformat}
> query = g.V.has('__guid','').copySplit(
>   _().out('track'), 
>   _().as('x')
>   .out('functions', 'component')
>   .loop('x'){true}{true}
>   .copySplit(
>   _(),
>   _().in('part_of'),
>   _().outE('functions', 
> 'component'),
>   _().inE('part_of')
>   )
>   .exhaustMerge.dedup
>   )
>   .exhaustMerge
> .collect()
> {noformat}
> this might not be a normal usecase. 
> edit to add: 
> I looked at GraphBackedDiscoveryService.java and notice that:
> 0.7:
> {code:java}
> else if (r instanceof TitanVertex) {
> Iterable ps = ((TitanVertex) 
> r).getProperties();
> for (TitanProperty tP : ps) {
> String pName = tP.getPropertyKey().getName();
> Object pValue = ((TitanVertex) r).getProperty(pName);
> if (pValue != null) {
> oRow.put(pName, pValue.toString());
> }
> }
> {code}
> Vs 0.8 code: 
> {code:java}
> else if (value instanceof AtlasVertex) {
> AtlasVertex vertex = (AtlasVertex)value;
> for (String key : vertex.getPropertyKeys()) {
> Object propertyValue = 
> GraphHelper.getProperty(vertex,  key);
> if (pro

[jira] [Commented] (ATLAS-1781) Atlas UI cannot show lineage pic when inputs and outputs of lineage are the same entity

2017-06-15 Thread Keval Bhatt (JIRA)

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

Keval Bhatt commented on ATLAS-1781:


[~xiaqinglin] Will create another bug if icon is not correct for process entity 
on master.
[~Xinzhi,Luo] as part of this bug can you please fix arrow color , other 
lineage items works fine.

> Atlas UI cannot show lineage pic when inputs and outputs of lineage are the 
> same entity
> ---
>
> Key: ATLAS-1781
> URL: https://issues.apache.org/jira/browse/ATLAS-1781
> Project: Atlas
>  Issue Type: Bug
>  Components: atlas-webui
>Affects Versions: trunk, 0.7-incubating, 0.8-incubating, 0.7.1-incubating, 
> 0.9-incubating
>Reporter: qinglin,xia
>Assignee: Xinzhi,Luo
>  Labels: atlas
> Fix For: 0.9-incubating
>
> Attachments: 0001-fix-ATLAS-1781.patch, 
> 0001-fix-not-working-with-more-than-2-nodes-with-ATLAS-17.patch, 
> after_test-wrong_op.png, browser_error.png, expected.png, fixed.png, Linage 
> fix not working with more than 2 nodes with ATLAS-1781.png, 
> Lineage_Create_Successfully_when_inputs_outputs_different.png, 
> Lineage_keep_loading.png, Process_Type_Not_Blue.png, 
> Starting_point_is_Impact_than_icon&arrow_colour_is_wrong(KEVAL_2_review).jpg
>
>
> I was working with the lineage for hbase, when I added a column family in a 
> hbase table, I want to create a lineage for the table to show there is a 
> change within the table schema, yet when I create a process using the atlas 
> api, I found that the process entity is successfully created, but the lineage 
> is not shown on the atlas web page.
> Steps to Reproduce this issue is: 
> 1. build up an entity extends the DataSet Type
> 2. build up a lineage Process
> 3. set the process input and output to the same entity
> The code is like:
> Referenceable table1 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, input_table_name);
> Referenceable table2 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, output_table_name);
> HBaseProcess process = new HBaseProcess("process");
> process.setInput(table1.getId());
> process.setoutput(table2.getId());
> here I set the input_table_name and output_table_name the same string name, 
> when I set them different values, the lineage pic can be shown for table1 and 
> table2 successfully
> Screenshots are:
> 1) The lineage pic keep loading on the atlas UI 
> 2) The error log reported by the browser console
> 3) The lineage pic showed successfully when set the inputs and outputs of the 
> lineage to different entities.  



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


[jira] [Comment Edited] (ATLAS-1781) Atlas UI cannot show lineage pic when inputs and outputs of lineage are the same entity

2017-06-15 Thread qinglin,xia (JIRA)

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

qinglin,xia edited comment on ATLAS-1781 at 6/15/17 10:55 AM:
--

[~kevalbhatt] Hi, Bhatt, thanks for your reply. 
But for your first expected point, I have did some tests and found that 
entities of Process type would not be shown on a blue color with gear icon on 
it, but when I used LoadProcess type and set time_dim as the input and output, 
the loadProcess node is a blue one, I think it might be a bug of Atlas. 

Please check the "Process_Type_Not_Blue" pic, the node test and test1 are both 
of Process type, and the node test2 is of "LoadProcess" type. 

Steps to reproduce: 
1. create a Process type entity test, set input and output to time_dim
2. create a Process type entity test1, set input to time_dim, output to 
sales_fact_monthly
3. create a LoadProcess type entity test2, set input and output to 
sales_fact_monthly


was (Author: xiaqinglin):
[~kevalbhatt] Hi, Bhatt, thanks for your reply. 
But for your first expected point, I have did some tests and found that 
entities of Process type would not be shown on a blue color with gear icon on 
it, but when I used LoadProcess type and set time_dim as the input and output, 
or time_dim as input, the loadProcess node is a blue one, I think it might be 
another bug. 

Please check the "Process_Type_Not_Blue" pic, the node test and test1 are both 
of Process type, and the node test2 is of "LoadProcess" type. 

Steps to reproduce: 
1. create a Process type entity test, set input and output to time_dim
2. create a Process type entity test1, set input to time_dim, output to 
sales_fact_monthly
3. create a LoadProcess type entity test2, set input and output to 
sales_fact_monthly

> Atlas UI cannot show lineage pic when inputs and outputs of lineage are the 
> same entity
> ---
>
> Key: ATLAS-1781
> URL: https://issues.apache.org/jira/browse/ATLAS-1781
> Project: Atlas
>  Issue Type: Bug
>  Components: atlas-webui
>Affects Versions: trunk, 0.7-incubating, 0.8-incubating, 0.7.1-incubating, 
> 0.9-incubating
>Reporter: qinglin,xia
>Assignee: Xinzhi,Luo
>  Labels: atlas
> Fix For: 0.9-incubating
>
> Attachments: 0001-fix-ATLAS-1781.patch, 
> 0001-fix-not-working-with-more-than-2-nodes-with-ATLAS-17.patch, 
> after_test-wrong_op.png, browser_error.png, expected.png, fixed.png, Linage 
> fix not working with more than 2 nodes with ATLAS-1781.png, 
> Lineage_Create_Successfully_when_inputs_outputs_different.png, 
> Lineage_keep_loading.png, Process_Type_Not_Blue.png, 
> Starting_point_is_Impact_than_icon&arrow_colour_is_wrong(KEVAL_2_review).jpg
>
>
> I was working with the lineage for hbase, when I added a column family in a 
> hbase table, I want to create a lineage for the table to show there is a 
> change within the table schema, yet when I create a process using the atlas 
> api, I found that the process entity is successfully created, but the lineage 
> is not shown on the atlas web page.
> Steps to Reproduce this issue is: 
> 1. build up an entity extends the DataSet Type
> 2. build up a lineage Process
> 3. set the process input and output to the same entity
> The code is like:
> Referenceable table1 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, input_table_name);
> Referenceable table2 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, output_table_name);
> HBaseProcess process = new HBaseProcess("process");
> process.setInput(table1.getId());
> process.setoutput(table2.getId());
> here I set the input_table_name and output_table_name the same string name, 
> when I set them different values, the lineage pic can be shown for table1 and 
> table2 successfully
> Screenshots are:
> 1) The lineage pic keep loading on the atlas UI 
> 2) The error log reported by the browser console
> 3) The lineage pic showed successfully when set the inputs and outputs of the 
> lineage to different entities.  



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


[jira] [Commented] (ATLAS-1781) Atlas UI cannot show lineage pic when inputs and outputs of lineage are the same entity

2017-06-15 Thread qinglin,xia (JIRA)

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

qinglin,xia commented on ATLAS-1781:


[~kevalbhatt] Hi, Bhatt, thanks for your reply. 
But for your first expected point, I have did some tests and found that 
entities of Process type would not be shown on a blue color with gear icon on 
it, but when I used LoadProcess type and set time_dim as the input and output, 
or time_dim as input, the loadProcess node is a blue one, I think it might be 
another bug. 

Please check the "Process_Type_Not_Blue" pic, the node test and test1 are both 
of Process type, and the node test2 is of "LoadProcess" type. 

Steps to reproduce: 
1. create a Process type entity test, set input and output to time_dim
2. create a Process type entity test1, set input to time_dim, output to 
sales_fact_monthly
3. create a LoadProcess type entity test2, set input and output to 
sales_fact_monthly

> Atlas UI cannot show lineage pic when inputs and outputs of lineage are the 
> same entity
> ---
>
> Key: ATLAS-1781
> URL: https://issues.apache.org/jira/browse/ATLAS-1781
> Project: Atlas
>  Issue Type: Bug
>  Components: atlas-webui
>Affects Versions: trunk, 0.7-incubating, 0.8-incubating, 0.7.1-incubating, 
> 0.9-incubating
>Reporter: qinglin,xia
>Assignee: Xinzhi,Luo
>  Labels: atlas
> Fix For: 0.9-incubating
>
> Attachments: 0001-fix-ATLAS-1781.patch, 
> 0001-fix-not-working-with-more-than-2-nodes-with-ATLAS-17.patch, 
> after_test-wrong_op.png, browser_error.png, expected.png, fixed.png, Linage 
> fix not working with more than 2 nodes with ATLAS-1781.png, 
> Lineage_Create_Successfully_when_inputs_outputs_different.png, 
> Lineage_keep_loading.png, Process_Type_Not_Blue.png, 
> Starting_point_is_Impact_than_icon&arrow_colour_is_wrong(KEVAL_2_review).jpg
>
>
> I was working with the lineage for hbase, when I added a column family in a 
> hbase table, I want to create a lineage for the table to show there is a 
> change within the table schema, yet when I create a process using the atlas 
> api, I found that the process entity is successfully created, but the lineage 
> is not shown on the atlas web page.
> Steps to Reproduce this issue is: 
> 1. build up an entity extends the DataSet Type
> 2. build up a lineage Process
> 3. set the process input and output to the same entity
> The code is like:
> Referenceable table1 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, input_table_name);
> Referenceable table2 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, output_table_name);
> HBaseProcess process = new HBaseProcess("process");
> process.setInput(table1.getId());
> process.setoutput(table2.getId());
> here I set the input_table_name and output_table_name the same string name, 
> when I set them different values, the lineage pic can be shown for table1 and 
> table2 successfully
> Screenshots are:
> 1) The lineage pic keep loading on the atlas UI 
> 2) The error log reported by the browser console
> 3) The lineage pic showed successfully when set the inputs and outputs of the 
> lineage to different entities.  



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


[jira] [Updated] (ATLAS-1781) Atlas UI cannot show lineage pic when inputs and outputs of lineage are the same entity

2017-06-15 Thread qinglin,xia (JIRA)

 [ 
https://issues.apache.org/jira/browse/ATLAS-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

qinglin,xia updated ATLAS-1781:
---
Attachment: Process_Type_Not_Blue.png

> Atlas UI cannot show lineage pic when inputs and outputs of lineage are the 
> same entity
> ---
>
> Key: ATLAS-1781
> URL: https://issues.apache.org/jira/browse/ATLAS-1781
> Project: Atlas
>  Issue Type: Bug
>  Components: atlas-webui
>Affects Versions: trunk, 0.7-incubating, 0.8-incubating, 0.7.1-incubating, 
> 0.9-incubating
>Reporter: qinglin,xia
>Assignee: Xinzhi,Luo
>  Labels: atlas
> Fix For: 0.9-incubating
>
> Attachments: 0001-fix-ATLAS-1781.patch, 
> 0001-fix-not-working-with-more-than-2-nodes-with-ATLAS-17.patch, 
> after_test-wrong_op.png, browser_error.png, expected.png, fixed.png, Linage 
> fix not working with more than 2 nodes with ATLAS-1781.png, 
> Lineage_Create_Successfully_when_inputs_outputs_different.png, 
> Lineage_keep_loading.png, Process_Type_Not_Blue.png, 
> Starting_point_is_Impact_than_icon&arrow_colour_is_wrong(KEVAL_2_review).jpg
>
>
> I was working with the lineage for hbase, when I added a column family in a 
> hbase table, I want to create a lineage for the table to show there is a 
> change within the table schema, yet when I create a process using the atlas 
> api, I found that the process entity is successfully created, but the lineage 
> is not shown on the atlas web page.
> Steps to Reproduce this issue is: 
> 1. build up an entity extends the DataSet Type
> 2. build up a lineage Process
> 3. set the process input and output to the same entity
> The code is like:
> Referenceable table1 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, input_table_name);
> Referenceable table2 = 
> atlasClient.getEntity(HBaseDataTypes.HBASE_TABLE_TYPE_NAME, 
> AtlasClient.REFERENCEABLE_ATTRIBUTE_NAME, output_table_name);
> HBaseProcess process = new HBaseProcess("process");
> process.setInput(table1.getId());
> process.setoutput(table2.getId());
> here I set the input_table_name and output_table_name the same string name, 
> when I set them different values, the lineage pic can be shown for table1 and 
> table2 successfully
> Screenshots are:
> 1) The lineage pic keep loading on the atlas UI 
> 2) The error log reported by the browser console
> 3) The lineage pic showed successfully when set the inputs and outputs of the 
> lineage to different entities.  



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


[jira] [Commented] (ATLAS-1875) Gremlin id is no longer returned for vertices in gremlin query

2017-06-15 Thread Graham Wallis (JIRA)

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

Graham Wallis commented on ATLAS-1875:
--

Hi Christian

I looked through the code and think that your proposed change would work. I 
have not tried it though; I would try to create a patch and test it but I don't 
know how to pull in the 0.7 or 0.8 version to build - I always build off the 
current master.

I noticed that, as you commented, in the "V2" API (which I assume to be 
AtlasDiscoveryService implemented by EntityDiscoveryService) there is no 
ability to search using gremlin directly. I don't know what the plan is for the 
"V1" API (which I assume to be the DiscoveryService implemented by 
GraphBackedDiscoveryService). Is that being removed at some time? If so I 
imagine it will raise the priority of sorting out the DSL performance issue in 
ATLAS-1868. Or is there a plan to enable gremlin queries in "V2"?

It's not clear from the code what the plan is around "V1" and "V2" and I've not 
managed to find anything or anyone to clarify it.



> Gremlin id is no longer returned for vertices in gremlin query
> --
>
> Key: ATLAS-1875
> URL: https://issues.apache.org/jira/browse/ATLAS-1875
> Project: Atlas
>  Issue Type: Bug
>  Components:  atlas-core
>Affects Versions: trunk, 0.8-incubating
>Reporter: Christian R
>  Labels: dsl, gremlin
>
> Hi, 
> while investigating a move from atlas 0.7 to 0.8 (HDP 2.5 to HDP2.6) our 
> tests fail on gremlin queries. It turns out that the returned entities in a 
> gremlin search in 0.8 does not include the 'id' attribute. 
> I've built commit a0bd93945cd45457bbf34a8cb819d4fa4ba72964 (0.8-rc1) on linux 
> using berkely and elasticearch to test with. 
> The query 
> :21000/api/atlas/discovery/search/gremlin?g.V.has('__type.name', 
> 'Infrastructure').collect()
> on our 0.7 cluster gives
> {code:json}
> {
> __type.name: "Infrastructure",
> __type.category: "CLASS",
> __type: "typeSystem",
> id: "16640"
> }{code}
> while the same query on my 0.8-rc1 installation gives 
> {code:javascript}
> {
> __type.name: "Infrastructure",
> __version: "1",
> __type.category: "CLASS",
> __type.version: "1.0",
> __modificationTimestamp: "1497448424134",
> __type: "typeSystem",
> __type.options: "null",
> __type.description: "Infrastructure",
> __guid: "77d07283-7622-4305-9c0c-09ac5aee86c8",
> __timestamp: "1497448424134"
> }
> {code}
> Certainly more information, but id is missing. 
> The very poor DSL performance (see  ATLAS-1868) and a need for advanced 
> queries led us to base our queries on gremlin. This has worked very well so 
> far. We include both edges and nodes in the result set and use the inVertex, 
> outVertex and label info on the edges to rebuild our tree on the client side.
> I also see that gremlin has disappeared from version two of the API. Since 
> addE and addV lets you insert into the graph I can see how exposing a full 
> gremlin endpoint might not be wanted. 
> As an example of the queries we run that I haven't been able to express in 
> the DSL is 
> {noformat}
> query = g.V.has('__guid','').copySplit(
>   _().out('track'), 
>   _().as('x')
>   .out('functions', 'component')
>   .loop('x'){true}{true}
>   .copySplit(
>   _(),
>   _().in('part_of'),
>   _().outE('functions', 
> 'component'),
>   _().inE('part_of')
>   )
>   .exhaustMerge.dedup
>   )
>   .exhaustMerge
> .collect()
> {noformat}
> this might not be a normal usecase. 
> edit to add: 
> I looked at GraphBackedDiscoveryService.java and notice that:
> 0.7:
> {code:java}
> else if (r instanceof TitanVertex) {
> Iterable ps = ((TitanVertex) 
> r).getProperties();
> for (TitanProperty tP : ps) {
> String pName = tP.getPropertyKey().getName();
> Object pValue = ((TitanVertex) r).getProperty(pName);
> if (pValue != null) {
> oRow.put(pName, pValue.toString());
> }
> }
> {code}
> Vs 0.8 code: 
> {code:java}
> else if (value instanceof AtlasVertex) {
> AtlasVertex vertex = (AtlasVertex)value;
> for (String key : vertex.getPropertyKeys()) {
> Object propertyValue = 
> GraphHelper.getProperty(vertex,  key);
> 

Build failed in Jenkins: apache-atlas-nightly #775

2017-06-15 Thread Apache Jenkins Server
See 


Changes:

[madhan] ATLAS-1873: renamed AtlasRelationshipEndPoint to AtlasRelationshipEnd

--
[...truncated 541.24 KB...]
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "GET 
/api/atlas/entities/03b8a3e2-6daa-4ddd-8196-492f34a8bc7b/traitDefinitions 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "GET 
/api/atlas/entities/0c4d2192-63ff-47ba-ae19-c0ad758092c9/traits HTTP/1.1" 200 - 
"-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST 
/api/atlas/entities/b8461991-38d5-419e-918b-b976aaf8d0e3 HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "GET 
/api/atlas/entities/b8461991-38d5-419e-918b-b976aaf8d0e3 HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST 
/api/atlas/entities/qualifiedName?type=hive_table&property=qualifiedName&value=tabletkSELgzVHu
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "GET 
/api/atlas/entities/b8461991-38d5-419e-918b-b976aaf8d0e3 HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "GET 
/api/atlas/entities/170b3415-b75e-4e49-9b0a-00d09f6cbe4e/audit?count=10 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:43 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/entities HTTP/1.1" 
400 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "GET 
/api/atlas/v2/types/typedef/name/GGEpOPV2eI HTTP/1.1" 404 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/types HTTP/1.1" 201 
- "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/entities HTTP/1.1" 
201 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "GET 
/api/atlas/entities/6ac57657-4c6d-4f4d-a14e-973b4ea141b8 HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "GET 
/api/atlas/v2/entity/guid/0d2451d3-4347-410c-9894-a69fe551310e HTTP/1.1" 200 - 
"-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/v2/entity/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST 
/api/atlas/v2/entity/guid/random/classifications HTTP/1.1" 404 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/v2/entity/bulk/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/v2/entity/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/v2/entity/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "DELETE 
/api/atlas/v2/entity/bulk/?guid=12756d75-7b07-454d-8dee-4d4a13091cd1&guid=a2779264-5a21-46d8-a3d9-75e5270b8912
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "POST /api/atlas/v2/entity/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "DELETE 
/api/atlas/v2/entity/uniqueAttribute/type/hive_db_v2?attr:name=dbtYHO1WH2fe%EA%82%A1%E5%8E%83%E6%B6%81%E4%B2%83%EB%91%AF%EB%BB%B7%E8%A8%B4%EF%98%81%E8%BA%A1%C3%96
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "DELETE 
/api/atlas/v2/entity/guid/random/classification/blah_trait HTTP/1.1" 400 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:53:44 +] "GET 
/api/atlas/discovery/search/dsl?query=hive_db_v2+where+name%3D'dbtYHO1WH2fe'&limit=10&offset=0
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:54:45 +] "POST /api/atlas/v2/types/typedefs/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:54:45 +] "POST /api/atlas/v2/entity/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:54:45 +] "PUT /api/atlas/v2/types/typedefs/ 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/2017:09:54:45 +] "GET 
/api/atlas/v2/entity/guid/80c17800-2b91-4464-9e18-ea686d0b456c HTTP/1.1" 200 - 
"-" "Java/1.7.0_80"
127.0.0.1 - - [15/Jun/201