Re: Current use cases for POST /entities

2016-09-13 Thread Shwetha Shivalingamurthy 
We can remove the definition, but I think we should return the guids.

The location in the response header contains the guid. But we should find
a way of returning all the guids created - probably list of locations?

When you change the create API, make sure to change even the update and
delete APIs.

Regards,
Shwetha




On 14/09/16, 3:46 AM, "Suma Shivaprasad" 
wrote:

>+1
>
>On Mon, Sep 12, 2016 at 9:22 PM, Apoorv Naik 
>wrote:
>
>> Is anyone relying on the definition object within the response of a
>>create
>> entity call ? If not, let¹s remove it from the response as it can be
>> inferred from the request body itself and the only useful piece seems
>>to be
>> the GUIDs.
>>

Re: Review Request 51660: [ATLAS-1098] Added keyword checks while creating a new tag/trait

2016-09-13 Thread Apoorv Naik 


> On Sept. 13, 2016, 4:40 a.m., Shwetha GS wrote:
> > repository/src/main/java/org/apache/atlas/services/DefaultMetadataService.java,
> >  line 309
> > 
> >
> > This is equals check - typename equals keyword. Does it work if 
> > typename contains keyword e.g., if typename is 'isa PII'?
> > 
> > Not sure if keywords in DSL is case sensitive. You may want to verify
> 
> Apoorv Naik wrote:
> Right now this will go through.
> 
> Apoorv Naik wrote:
> I've tried changing the case but seems like the dsl is not case sensitive 
> for those keywords

While testing, I see that if the keyword has any prefix or suffix separated by 
a space. The query parser doesn't break. Is that what you're looking for ?


- Apoorv


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


On Sept. 6, 2016, 11:27 p.m., Apoorv Naik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51660/
> ---
> 
> (Updated Sept. 6, 2016, 11:27 p.m.)
> 
> 
> Review request for atlas, Madhan Neethiraj, Shwetha GS, Suma Shivaprasad, and 
> Vimal Sharma.
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> [ATLAS-1098] Added keyword checks while creating a new tag/trait
> 
> 
> Diffs
> -
> 
>   
> repository/src/main/java/org/apache/atlas/services/DefaultMetadataService.java
>  4d05d49 
> 
> Diff: https://reviews.apache.org/r/51660/diff/
> 
> 
> Testing
> ---
> 
> Tested with all possible keywords specified in the QueryParser, the UI shows 
> a red exception message stating that the type being created is a keyword
> 
> 
> Thanks,
> 
> Apoorv Naik
> 
>

Re: Current use cases for POST /entities

2016-09-13 Thread Suma Shivaprasad 
+1

On Mon, Sep 12, 2016 at 9:22 PM, Apoorv Naik  wrote:

> Is anyone relying on the definition object within the response of a create
> entity call ? If not, let’s remove it from the response as it can be
> inferred from the request body itself and the only useful piece seems to be
> the GUIDs.
>

[jira] [Commented] (ATLAS-712) Support getTrait() API

2016-09-13 Thread Suma Shivaprasad (JIRA) 

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

Suma Shivaprasad commented on ATLAS-712:


Can you pls modify the test as well to go through AtlasClient. Rest looks good.

> Support getTrait() API
> --
>
> Key: ATLAS-712
> URL: https://issues.apache.org/jira/browse/ATLAS-712
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Suma Shivaprasad
>Assignee: Vimal Sharma
> Attachments: ATLAS-712-v2.patch, ATLAS-712.patch
>
>
> Given entity id and trait name, support rest API that returns the trait 
> instance for the entity. Currently, the other way of getting it is 
> getEntity() which returns full entity with all trait instances 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ATLAS-1164) Separate the resource defintions from the exposed REST API.

2016-09-13 Thread David Radley (JIRA) 
David Radley created ATLAS-1164:
---

 Summary: Separate the resource defintions from the exposed REST 
API. 
 Key: ATLAS-1164
 URL: https://issues.apache.org/jira/browse/ATLAS-1164
 Project: Atlas
  Issue Type: Improvement
Reporter: David Radley


 in Atlas. I suggest that REST orientated processing be kept separate from the 
data to promote a loose coupling. I suggest the 2 validate payload methods in 
ResourceDefintion and other REST processing be moved out of the current project 
with other REST orientated processing to an API specific project. In this way 
we can separate the base resource model from the exposed API. This separation 
would allow us to expose multiple APIs, different ones for different consumers 
in the future; for example one for the discovery tooling to use one for asset 
management tooling.   
 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-1161) Tags should be bound to an object's name and remain bound to all incarnations of that name

2016-09-13 Thread Shwetha G S (JIRA) 

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

Shwetha G S commented on ATLAS-1161:


{quote}
In the current Atlas world, if I create TableA again, Tag1 and Tag2 need to be 
re-applied to TableA
{quote}
I think it makes sense to not carry over the tags from old entity. The new 
entity, even though has the same name as old entity, might have been derived in 
a different way and mean something else. Even I think rule based classification 
would be a better fit here.

{quote}
By effectively deleting the binding of Tag1 and Tag2 to the name TableA 
whenever TableA is deleted, Atlas ceases to be a book of record for tags 
associated with TableA, as those tags would need to be applied again.
{quote}
By default, entity deletes are soft deletes. So, when TableA is deleted, its 
just marked as deleted and all the tag associations still remain and search 
retrieves the deleted entities as well. When TableA is re-created, atlas 
creates another entity(with new guid) and with no tags. So, both the old and 
new entity exists and its possible to look at both of them for audit. 
Additionally, each entity has audit trail that records tag associations, that 
can be viewed for both active and deleted entities

> Tags should be bound to an object's name and remain bound to all incarnations 
> of that name
> --
>
> Key: ATLAS-1161
> URL: https://issues.apache.org/jira/browse/ATLAS-1161
> Project: Atlas
>  Issue Type: Improvement
>Affects Versions: trunk, 0.7-incubating
>Reporter: Dan Markwat
>
> As a user I would like tags I ascribe to an object in Atlas carry to the next 
> incarnation of that object.  In effect, tags would be ascribed to a 
> fully-qualified object name and all incarnations of that name would have the 
> tags apply to it.  (Not unlike Ranger and the way it applies policies to 
> objects).
> Example: I create a Hive table, TableA.  I tag TableA with tags, Tag1 and 
> Tag2.  I drop TableA.
> In the current Atlas world, if I create TableA again, Tag1 and Tag2 need to 
> be re-applied to TableA.  In the ideal governance/security world, if I 
> re-create TableA I should not have to re-tag it with Tag1 and Tag2; instead, 
> I should be required to *untag* TableA if I desire TableA to be clean and 
> untagged.  This effectively functions like a light switch: user turns on 
> light, just because the bulb is swapped out doesn't mean the switch turned 
> off - the user must explicitly turn the switch off, just as they did to turn 
> it on.  Think also about Ranger: just because I deleted an object doesn't 
> mean that policy goes away.
> By effectively deleting the binding of Tag1 and Tag2 to the name TableA 
> whenever TableA is deleted, Atlas ceases to be a book of record for tags 
> associated with TableA, as those tags would need to be applied again.  This 
> is bad in a world where creating/dropping objects and tagging objects are 
> part of 2 independent and asynchronous processes - one carried out by an 
> engineer, the other carried out by a governance/security administrator.  The 
> issue is compounded by the fact that tags can have security policies 
> associated with them in Ranger; and any object missing its tag at re-creation 
> of that object now is missing security policies previously attached to it.
> This is an especially annoying issue for organizations that have large 
> ingestion pipelines where tables are sometimes deleted or modified in ways 
> not easily accomplished through updating table metadata.  Not to mention, 
> (probably a new feature: ) easily-accessible records of what was tagged with 
> what - even if the object has been dropped or deleted - is especially 
> important for organizations that require auditing or have security controls 
> based on tag-based policies.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 51515: ATLAS-772 : New attribute has been added to the hive_column type to capture the position of hive columns for sorting

2016-09-13 Thread Shwetha GS 

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




addons/hive-bridge/src/main/java/org/apache/atlas/hive/bridge/HiveMetaStoreBridge.java
 (line 588)


Can you add tests that column position is set correctly in create table and 
alter table column reorder? You can add extra validations in existing tests as 
well


- Shwetha GS


On Aug. 30, 2016, 6:20 a.m., Sarath Kumar Subramanian wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51515/
> ---
> 
> (Updated Aug. 30, 2016, 6:20 a.m.)
> 
> 
> Review request for atlas, Madhan Neethiraj and Suma Shivaprasad.
> 
> 
> Bugs: ATLAS-772
> https://issues.apache.org/jira/browse/ATLAS-772
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> When a schema query is issued against a hive table, the hive_column entities 
> are retrieved from the titan database. Each hive_column entity is a vertex in 
> titan and currently titan doesn't store any column order position in its 
> vertex attributes. The hive_columns are retrieved in the sort order of the 
> Vertex ID which is not same as the Hive column order position. The fix 
> attached is to introduce a new "position" attribute in hive_column type, 
> which maintains the column order position. This column order position can be 
> consumed by any clients - including UI to display the columns in the original 
> position/order.
> 
> 
> Diffs
> -
> 
>   
> addons/hive-bridge/src/main/java/org/apache/atlas/hive/bridge/HiveMetaStoreBridge.java
>  1f13d74 
>   
> addons/hive-bridge/src/main/java/org/apache/atlas/hive/model/HiveDataModelGenerator.java
>  b308cc9 
> 
> Diff: https://reviews.apache.org/r/51515/diff/
> 
> 
> Testing
> ---
> 
> Tested the changes with hive column operations – Add new column, Drop column, 
> Rename column, Move column to first or at a position.
> 
> 
> Thanks,
> 
> Sarath Kumar Subramanian
> 
>

Re: Review Request 51800: Support getTrait() API

2016-09-13 Thread Vimal Sharma 

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

(Updated Sept. 13, 2016, 11:12 a.m.)


Review request for atlas.


Repository: atlas


Description
---

Given entity id and trait name, support rest API that returns the trait 
instance for the entity. Currently, the other way of getting it is getEntity() 
which returns full entity with all trait instances


Diffs
-

  webapp/src/main/java/org/apache/atlas/web/resources/EntityResource.java 
82016d0 
  
webapp/src/test/java/org/apache/atlas/web/resources/EntityJerseyResourceIT.java 
a1988ef 

Diff: https://reviews.apache.org/r/51800/diff/


Testing
---


File Attachments (updated)


ATLAS-712-v2.patch
  
https://reviews.apache.org/media/uploaded/files/2016/09/13/b5079426-19d0-48f2-88f7-08e4e645bb32__ATLAS-712-v2.patch


Thanks,

Vimal Sharma

Re: Review Request 51800: Support getTrait() API

2016-09-13 Thread Vimal Sharma 


> On Sept. 12, 2016, 2:07 p.m., David Radley wrote:
> > I am was thinking that a more intuitive API would be to follow the pattern 
> > used in the REST API for entities. So for entities with have 
> > .../entities/{entityguid}. So for consistancy we could have
> > .../entities/{entityguid}/traitnames which would return all the traitnames 
> > for the entity.   
> > .../entities/{entityguid}/traitnames/{traitname} which would return the 
> > specified traitname for the entity.

It makes sense to have separate endpoints for all trait definitions and 
individual trait definition. I have made this change in the new patch.


- Vimal


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


On Sept. 12, 2016, 11:09 a.m., Vimal Sharma wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51800/
> ---
> 
> (Updated Sept. 12, 2016, 11:09 a.m.)
> 
> 
> Review request for atlas.
> 
> 
> Repository: atlas
> 
> 
> Description
> ---
> 
> Given entity id and trait name, support rest API that returns the trait 
> instance for the entity. Currently, the other way of getting it is 
> getEntity() which returns full entity with all trait instances
> 
> 
> Diffs
> -
> 
>   webapp/src/main/java/org/apache/atlas/web/resources/EntityResource.java 
> 82016d0 
>   
> webapp/src/test/java/org/apache/atlas/web/resources/EntityJerseyResourceIT.java
>  a1988ef 
> 
> Diff: https://reviews.apache.org/r/51800/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vimal Sharma
> 
>

[jira] [Commented] (ATLAS-712) Support getTrait() API

2016-09-13 Thread Vimal Sharma (JIRA) 

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

Vimal Sharma commented on ATLAS-712:


Made corresponding changes in AtlasClient. Modified API endpoints as suggested 
by [~davidrad] on review board.

> Support getTrait() API
> --
>
> Key: ATLAS-712
> URL: https://issues.apache.org/jira/browse/ATLAS-712
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Suma Shivaprasad
>Assignee: Vimal Sharma
> Attachments: ATLAS-712-v2.patch, ATLAS-712.patch
>
>
> Given entity id and trait name, support rest API that returns the trait 
> instance for the entity. Currently, the other way of getting it is 
> getEntity() which returns full entity with all trait instances 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ATLAS-712) Support getTrait() API

2016-09-13 Thread Vimal Sharma (JIRA) 

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

Vimal Sharma updated ATLAS-712:
---
Attachment: ATLAS-712-v2.patch

> Support getTrait() API
> --
>
> Key: ATLAS-712
> URL: https://issues.apache.org/jira/browse/ATLAS-712
> Project: Atlas
>  Issue Type: Improvement
>Reporter: Suma Shivaprasad
>Assignee: Vimal Sharma
> Attachments: ATLAS-712-v2.patch, ATLAS-712.patch
>
>
> Given entity id and trait name, support rest API that returns the trait 
> instance for the entity. Currently, the other way of getting it is 
> getEntity() which returns full entity with all trait instances 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ATLAS-1161) Tags should be bound to an object's name and remain bound to all incarnations of that name

2016-09-13 Thread David Radley (JIRA) 

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

David Radley commented on ATLAS-1161:
-

Interesting - thanks [~dmarkwat] 
- it seems that the asset in question is like a transient file. I assume that 
the sort of use case you are thinking of is a delta ETL / map reduce jobs, 
where you accumulate daily updates in a table. You may be deleting and 
recreating files as part of this process. A way of doing this would be to use 
the time stamp in the file name or the folder name / namespace. It seems to me 
that a more complete solution would be use rules based classification / tagging 
- e.g. everything in this folder or with this namespace regex could be 
automatically tagged / classified; this could catch renames as well. It might 
that where a file lives brings picks up its classification - so one way of 
changing the classification of an asset would be to move it to a new location. 
- I guess your suggested solution is a useful improvement; though I think the 
company setting this up needs to buy into this sort of behaviour with a config 
option or new API or new atlas type;  so that there i no unintended 
consequences for other use cases. Usual practice would be to not change 
defaults , but I guess in an incubator if we feel this default is more useful 
then this could be the default behavior. 
- Another way of doing this classification would be that the ETL / map reduce 
job does the classification of the target table. It could then also do more 
granular column based tagging as well. The responsibility of the classification 
then lies with the job that creates the file. 
- I suspect we would often not tag a table as PII - more likely a column. 
Though we might tag a table as "customer data" or "for testing"  or the like. 

> Tags should be bound to an object's name and remain bound to all incarnations 
> of that name
> --
>
> Key: ATLAS-1161
> URL: https://issues.apache.org/jira/browse/ATLAS-1161
> Project: Atlas
>  Issue Type: Improvement
>Affects Versions: trunk, 0.7-incubating
>Reporter: Dan Markwat
>
> As a user I would like tags I ascribe to an object in Atlas carry to the next 
> incarnation of that object.  In effect, tags would be ascribed to a 
> fully-qualified object name and all incarnations of that name would have the 
> tags apply to it.  (Not unlike Ranger and the way it applies policies to 
> objects).
> Example: I create a Hive table, TableA.  I tag TableA with tags, Tag1 and 
> Tag2.  I drop TableA.
> In the current Atlas world, if I create TableA again, Tag1 and Tag2 need to 
> be re-applied to TableA.  In the ideal governance/security world, if I 
> re-create TableA I should not have to re-tag it with Tag1 and Tag2; instead, 
> I should be required to *untag* TableA if I desire TableA to be clean and 
> untagged.  This effectively functions like a light switch: user turns on 
> light, just because the bulb is swapped out doesn't mean the switch turned 
> off - the user must explicitly turn the switch off, just as they did to turn 
> it on.  Think also about Ranger: just because I deleted an object doesn't 
> mean that policy goes away.
> By effectively deleting the binding of Tag1 and Tag2 to the name TableA 
> whenever TableA is deleted, Atlas ceases to be a book of record for tags 
> associated with TableA, as those tags would need to be applied again.  This 
> is bad in a world where creating/dropping objects and tagging objects are 
> part of 2 independent and asynchronous processes - one carried out by an 
> engineer, the other carried out by a governance/security administrator.  The 
> issue is compounded by the fact that tags can have security policies 
> associated with them in Ranger; and any object missing its tag at re-creation 
> of that object now is missing security policies previously attached to it.
> This is an especially annoying issue for organizations that have large 
> ingestion pipelines where tables are sometimes deleted or modified in ways 
> not easily accomplished through updating table metadata.  Not to mention, 
> (probably a new feature: ) easily-accessible records of what was tagged with 
> what - even if the object has been dropped or deleted - is especially 
> important for organizations that require auditing or have security controls 
> based on tag-based policies.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ATLAS-1163) Sorting of hive table columns based on position attribute at server end instead UI.

2016-09-13 Thread Nixon Rodrigues (JIRA) 

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

Nixon Rodrigues updated ATLAS-1163:
---
Description: 
The UI shouldn't do the sort. Instead we should modify the query used for this 
(atlas.lineage.schema.query.hive_table=hive_table where __guid='%s'\, columns) 
to sort by position, so that all clients have the same info. Also, the query 
should filter deleted columns

The UI level sort was in done in [ATLAS-1149]

  was:
The UI shouldn't do the sort. Instead we should modify the query used for this 
(atlas.lineage.schema.query.hive_table=hive_table where __guid='%s'\, columns) 
to sort by position, so that all clients have the same info. Also, the query 
should filter deleted columns

The UI level sort was in done in [ATLAS-1147]


> Sorting of hive table columns based on position attribute at server end 
> instead UI.
> ---
>
> Key: ATLAS-1163
> URL: https://issues.apache.org/jira/browse/ATLAS-1163
> Project: Atlas
>  Issue Type: Bug
>Reporter: Nixon Rodrigues
>
> The UI shouldn't do the sort. Instead we should modify the query used for 
> this (atlas.lineage.schema.query.hive_table=hive_table where __guid='%s'\, 
> columns) to sort by position, so that all clients have the same info. Also, 
> the query should filter deleted columns
> The UI level sort was in done in [ATLAS-1149]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

2016-09-13 Thread Apache Jenkins Server 
See 

Changes:

[kbhatt] ATLAS-1149 Changes to UI to sort the hive table schema based on 
position

[kbhatt] ATLAS-1133 Jetty Server start doesn't throw exception when

--
[...truncated 9070 lines...]
127.0.0.1 - - [13/Sep/2016:06:46:05 +] "GET 
/api/atlas/lineage/hive/table/default.tablelbkko7tini@primary/inputs/graph 
HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:09 +] "GET 
/api/atlas/entities?type=hive_process=qualifiedName=QUERY:default.tableki2ltffnyj@primary:1473749168000-%3E:PATH_WRITE
 HTTP/1.1" 404 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities?type=hive_process=qualifiedName=QUERY:default.tableki2ltffnyj@primary:1473749168000-%3E:PATH_WRITE
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities?type=hive_process=qualifiedName=QUERY:default.tableki2ltffnyj@primary:1473749168000-%3E:PATH_WRITE
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities/6bd6df94-5c0a-40a7-a1db-cfde8136ee6f HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities/3614a473-3169-4a99-9a4f-dbbc856dab32 HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities/1f860f71-c591-49a4-9cf5-a4846dfc7f6f HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities?type=hdfs_path=qualifiedName=p
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities?type=hdfs_path=qualifiedName=p
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities/1f860f71-c591-49a4-9cf5-a4846dfc7f6f HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities?type=hive_table=qualifiedName=default.tableki2ltffnyj@primary
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities?type=hive_table=qualifiedName=default.tableki2ltffnyj@primary
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:14 +] "GET 
/api/atlas/entities/3614a473-3169-4a99-9a4f-dbbc856dab32 HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities?type=hive_table=qualifiedName=default.tableki2ltffnyj@primary
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities?type=hive_table=qualifiedName=default.tableki2ltffnyj@primary
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities?type=hive_process=qualifiedName=QUERY:default.tableki2ltffnyj@primary:1473749168000-%3E:PATH_WRITE
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities?type=hive_process=qualifiedName=QUERY:default.tableki2ltffnyj@primary:1473749168000-%3E:PATH_WRITE
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities/6bd6df94-5c0a-40a7-a1db-cfde8136ee6f HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities/3614a473-3169-4a99-9a4f-dbbc856dab32 HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities/1f860f71-c591-49a4-9cf5-a4846dfc7f6f HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities?type=hdfs_path=qualifiedName=p
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities?type=hdfs_path=qualifiedName=p
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:17 +] "GET 
/api/atlas/entities/1f860f71-c591-49a4-9cf5-a4846dfc7f6f HTTP/1.1" 200 - "-" 
"Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:19 +] "GET 
/api/atlas/entities?type=hive_table=qualifiedName=default.tableki2ltffnyj@primary
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:19 +] "GET 
/api/atlas/entities?type=hive_table=qualifiedName=default.tableki2ltffnyj@primary
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - - [13/Sep/2016:06:46:19 +] "GET 
/api/atlas/entities?type=hive_process=qualifiedName=QUERY:default.tableki2ltffnyj@primary:1473749168000-%3E:PATH_WRITE
 HTTP/1.1" 200 - "-" "Java/1.7.0_80"
127.0.0.1 - -

[jira] [Created] (ATLAS-1163) Sorting of hive table columns based on position attribute at server end instead UI.

2016-09-13 Thread Nixon Rodrigues (JIRA) 
Nixon Rodrigues created ATLAS-1163:
--

 Summary: Sorting of hive table columns based on position attribute 
at server end instead UI.
 Key: ATLAS-1163
 URL: https://issues.apache.org/jira/browse/ATLAS-1163
 Project: Atlas
  Issue Type: Bug
Reporter: Nixon Rodrigues


The UI shouldn't do the sort. Instead we should modify the query used for this 
(atlas.lineage.schema.query.hive_table=hive_table where __guid='%s'\, columns) 
to sort by position, so that all clients have the same info. Also, the query 
should filter deleted columns

The UI level sort was in done in [ATLAS-1147]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)