Mailing-List: contact dev-help@atlas.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@atlas.apache.org
Date: Mon, 20 Nov 2017 17:16:00 +0000 (UTC)
From: "Graham Wallis (JIRA)" <jira@apache.org>
To: dev@atlas.apache.org
Message-ID: <JIRA.13118929.1510843062000.281609.1511198160819@Atlassian.JIRA>
In-Reply-To: <JIRA.13118929.1510843062000@Atlassian.JIRA>
References: <JIRA.13118929.1510843062000@Atlassian.JIRA> <JIRA.13118929.1510843062912@jira-lw-us.apache.org>
Subject: [jira] [Commented] (ATLAS-2262) EntityGraphMapper update semantics
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 20 Nov 2017 17:16:05 -0000


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

Graham Wallis commented on ATLAS-2262:
--------------------------------------

Updated patch and review following Madhan's review comments.

> EntityGraphMapper update semantics
> ----------------------------------
>
>                 Key: ATLAS-2262
>                 URL: https://issues.apache.org/jira/browse/ATLAS-2262
>             Project: Atlas
>          Issue Type: Bug
>            Reporter: Graham Wallis
>            Assignee: Graham Wallis
>            Priority: Minor
>         Attachments: ATLAS-2262-v2.patch, ATLAS-2262.patch
>
>
> Intermittent failures in AtlasRelationshipStoreV1Test occur during modification of the 'friends' relationships between sample Employee and Manager entities. 
> The intermittent failures are seen as different numbers of updated entities being reported, which causes the test assertion to fail. The failures are intermittent because they are caused by non-deterministic behaviour during UPDATE of an entity's relationships. The non-determinism is caused by the order in which results are returned by a graph query, although any order should be considered valid.
> When built with graph provider titan0, the order of edges returned from the graph is always the same, and the current EntityGraphMapper returns a consistent result. The way it achieves it is slightly odd, with existing edge reuse depending on the position of the edge in the returned list. But with titan0, the behaviour is consistent, and correct.
> When using the janus graph provider, the order of edges returned from the graph varies. This is valid behaviour on the part of the graph, but the EntityGraphMapper does not behave the same when the edges are returned in a different order compared to titan0.
> There are two levels of problem: The first is accuracy of the returned count of updated entities; the second and in my opinion more important is the semantics of an update operation that presents the same array of entity relationships in an order that is not the same as the order returned by the graph. In my opinion the result of the UPDATE operation should not vary depending on the order of the edges returned by the internal graph query. If the set of related entities presented matches the set already recorded then the existing related entities should be reused, rather than replaced. It is therefore the latter problem that I have been working on. 


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