atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Wallis (JIRA)" <>
Subject [jira] [Updated] (ATLAS-2262) EntityGraphMapper update semantics
Date Mon, 20 Nov 2017 17:15:00 GMT


Graham Wallis updated ATLAS-2262:
    Attachment: ATLAS-2262-v2.patch

> EntityGraphMapper update semantics
> ----------------------------------
>                 Key: ATLAS-2262
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message