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

Stephen Mallette closed TINKERPOP-2935.
---------------------------------------
    Resolution: Won't Do

> Better extensibility around user supplied ids with certain test patterns for 
> gherkin
> ------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-2935
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2935
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: test-suite
>    Affects Versions: 3.6.2
>            Reporter: Stephen Mallette
>            Priority: Major
>         Attachments: StepDefinition.diff.txt
>
>
> Using this test in {{MergedEdge.feature}} as an example:
> {code}
>   @UserSuppliedVertexIds
>   Scenario: g_mergeEXlabel_knows_out_marko_in_vadasX
>     Given the empty graph
>     And the graph initializer of
>       """
>       g.addV("person").property(T.id, 100).property("name", "marko").
>         addV("person").property(T.id, 101).property("name", "vadas")
>       """
>     And using the parameter xx1 defined as "m[{\"t[label]\": \"knows\", 
> \"D[OUT]\":\"v[100]\", \"D[IN]\":\"v[101]\"}]"
>     And the traversal of
>       """
>       g.mergeE(xx1)
>       """
>     When iterated to list
>     Then the result should have a count of 1
>     And the graph should return 1 for count of 
> "g.V().has(\"person\",\"name\",\"marko\").out(\"knows\").has(\"person\",\"name\",\"vadas\")"
> {code}
> it correctly tags with {{UserSuppliedVertexIds}} but if the graph doesn't 
> support {{Numeric}} ids then it's going to be in trouble. Ultimately, these 
> sorts of tests are important for ensuring the complex semantics of 
> {{mergeV()}} and {{mergeE()}} are supported properly so it's bad that graphs 
> will have to line-item ignore them. 
> A rough idea would be to let parameters be applied to complex parameters like 
> {{Map}} and {{List}} and to apply parameters to "the graph initializer" the 
> same way we do to "the traversal of". A quick test (see attached diff file) 
> shows that this works for Java and this revision to the test structure:
> {code}
>   @UserSuppliedVertexIds
>   Scenario: g_mergeEXlabel_knows_out_marko_in_vadasX
>     Given the empty graph
>     And using the parameter vid100 defined as "v[100].id"
>     And using the parameter vid101 defined as "v[101].id"
>     And using the parameter xx1 defined as "m[{\"t[label]\": \"knows\", 
> \"D[OUT]\":\"v[vid100]\", \"D[IN]\":\"v[vid101]\"}]"
>     And the graph initializer of
>       """
>       g.addV("person").property(T.id, vid100).property("name", "marko").
>         addV("person").property(T.id, vid101).property("name", "vadas")
>       """
>     And the traversal of
>       """
>       g.mergeE(xx1)
>       """
>     When iterated to list
>     Then the result should have a count of 1
>     And the graph should return 1 for count of 
> "g.V().has(\"person\",\"name\",\"marko\").out(\"knows\").has(\"person\",\"name\",\"vadas\")"
> {code}
> Not sure if this is ideal but it works. Open to other solutions that might be 
> better if anyone can suggest any.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to