atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashutosh Mestry <ames...@hortonworks.com>
Subject Re: Review Request 68270: Cluster Entity Updated after Successful Import if Replication Options are Available in Import Request
Date Tue, 14 Aug 2018 18:00:34 GMT


> On Aug. 14, 2018, 6:34 a.m., Madhan Neethiraj wrote:
> > intg/src/main/java/org/apache/atlas/model/clusterinfo/AtlasCluster.java
> > Lines 85 (patched)
> > <https://reviews.apache.org/r/68270/diff/5/?file=2071985#file2071985line92>
> >
> >     Use of stringified-AtlasObjectId as key doesn't sound good - since AtlasObjectId
has guid/type/state/uniqueAttributes. Why not simply use entiy guid as the key?

Since objectId is the top-level entity, GUID will not be set in most cases. Hence we cannot
use GUID.


> On Aug. 14, 2018, 6:34 a.m., Madhan Neethiraj wrote:
> > intg/src/main/java/org/apache/atlas/model/impexp/ReplicationDetails.java
> > Lines 37 (patched)
> > <https://reviews.apache.org/r/68270/diff/5/?file=2071988#file2071988line37>
> >
> >     Why is it necessary to store operation & lastUpdate values? Only lastModifiedTimestamp
should be enough, right? I suggest to avoid ReplicationDetails class completely and instead
have the caller:
> >     - retrieve AtlasCluster
> >     - read additionalInfo.get("REPL_STATUS").get(entityGuid) <== this should
return the modifiedTime of the entity during previous repl-import
> >     
> >     In addition, remove AdminResource.getReplicationDetails() and AtlasBaseClient.getReplicationDetails()

Operation is necessary, we need to know the purpose of the cluster. Given 2 clusters, one
is current cluster and one is data being exported to, there is nowhere we denote what is the
operation being performed on that cluster.

In scenario, where multiple exports and imports are being performed, this will be even more
important.


> On Aug. 14, 2018, 6:34 a.m., Madhan Neethiraj wrote:
> > repository/src/main/java/org/apache/atlas/repository/impexp/ExportImportAuditService.java
> > Lines 83 (patched)
> > <https://reviews.apache.org/r/68270/diff/5/?file=2071991#file2071991line83>
> >
> >     "result.getEntities() == null" - perhaps you meant "result == null"?

Result is not null always. If there are no entities, then getEntities returns null.


- Ashutosh


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


On Aug. 14, 2018, 6 p.m., Ashutosh Mestry wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/68270/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2018, 6 p.m.)
> 
> 
> Review request for atlas, Apoorv Naik, Madhan Neethiraj, and Sarath Subramanian.
> 
> 
> Bugs: ATLAS-2814
>     https://issues.apache.org/jira/browse/ATLAS-2814
> 
> 
> Repository: atlas
> 
> 
> Description
> -------
> 
> **Approach**
> - New model _ReplicationDetails_ store replication timestamp.
> - _AuditWriter_ updates appropriate _AtlasCluster_ entity with _ReplicationDetails_.
> 
> **REST Call**
> Endpoint: /admin/expimp/audit
> CURL:
> curl -X GET -u admin:admin -H "Content-Type: application/json" -H "Cache-Control: no-cache"
http://localhost:21000/api/atlas/admin/expimp/audit?cluster=cl2
> 
> 
> Diffs
> -----
> 
>   webapp/src/test/resources/stocks-base.zip 40c7f37eefb46a944921f6a74a916191704cb9a3

> 
> 
> Diff: https://reviews.apache.org/r/68270/diff/6/
> 
> 
> Testing
> -------
> 
> **Unit tests**
> New tests added.
> Unit tests related to audits now pause for 5 secs before performing asserts. This should
give time for indexes to be created.
> 
> 
> Thanks,
> 
> Ashutosh Mestry
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message