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

ASF GitHub Bot commented on TINKERPOP-3137:
-------------------------------------------

Cole-Greer commented on code in PR #3055:
URL: https://github.com/apache/tinkerpop/pull/3055#discussion_r1964444635


##########
gremlin-test/src/main/resources/org/apache/tinkerpop/gremlin/test/features/map/MergeEdge.feature:
##########
@@ -947,4 +947,45 @@ Feature: Step - mergeE()
     And the graph should return 7 for count of "g.E()"
     And the graph should return 7 for count of "g.E().hasNot(\"created\")"
     And the graph should return 1 for count of 
"g.V().has(\"person\",\"name\",\"marko\").outE(\"knows\").hasNot(\"created\").inV().has(\"person\",\"name\",\"vadas\")"
-    And the graph should return 1 for count of 
"g.V().has(\"person\",\"name\",\"vadas\").outE(\"self\").hasNot('weight').inV().has(\"person\",\"name\",\"vadas\")"
\ No newline at end of file
+    And the graph should return 1 for count of 
"g.V().has(\"person\",\"name\",\"vadas\").outE(\"self\").hasNot('weight').inV().has(\"person\",\"name\",\"vadas\")"
+
+  @AllowNullPropertyValues
+  Scenario: 
g_mergeEXlabel_knows_out_marko_in_vadasX_optionXonMatch_weight_nullX_allowed
+    Given the empty graph
+    And the graph initializer of
+      """
+      g.addV("person").property("name", "marko").as("a").
+        addV("person").property("name", "vadas").as("b").
+        addE("knows").from("a").to("b").property("weight",1.0d)
+      """
+    And using the parameter xx1 defined as "m[{\"t[label]\": \"knows\", 
\"D[OUT]\":\"v[marko]\", \"D[IN]\":\"v[vadas]\"}]"
+    And using the parameter xx2 defined as "m[{\"weight\":null}]"
+    And the traversal of
+      """
+      g.mergeE(xx1).option(Merge.onMatch,xx2)
+      """
+    When iterated to list
+    Then the result should have a count of 1
+    And the graph should return 2 for count of "g.V()"
+    And the graph should return 1 for count of "g.E().hasLabel(\"knows\")"
+    And the graph should return 1 for count of 
"g.E().hasLabel(\"knows\").has(\"weight\",null)"
+
+  Scenario: 
g_mergeEXlabel_knows_out_marko_in_vadasX_optionXonMatch_weight_nullX
+    Given the empty graph
+    And the graph initializer of
+      """
+      g.addV("person").property("name", "marko").as("a").
+        addV("person").property("name", "vadas").as("b").
+        addE("knows").from("a").to("b").property("weight",1.0d)
+      """
+    And using the parameter xx1 defined as "m[{\"t[label]\": \"knows\", 
\"D[OUT]\":\"v[marko]\", \"D[IN]\":\"v[vadas]\"}]"
+    And using the parameter xx2 defined as "m[{\"weight\":null}]"
+    And the traversal of
+      """
+      g.mergeE(xx1).option(Merge.onMatch,xx2)
+      """
+    When iterated to list
+    Then the result should have a count of 1
+    And the graph should return 2 for count of "g.V()"
+    And the graph should return 1 for count of "g.E().hasLabel(\"knows\")"
+    And the graph should return 0 for count of 
"g.E().hasLabel(\"knows\").has(\"weight\")"

Review Comment:
   Keeping the focus on the new scenarios added in this PR, I don't see how a 
single Graph instance could ever pass both new scenarios at once. The 2 new 
scenarios have the same initialization and query, but have contradicting 
assertions. Any graph implementation must skip at least one of these scenarios.





> Allow null to be used as Map value to mergeV and mergeE
> -------------------------------------------------------
>
>                 Key: TINKERPOP-3137
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-3137
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.7.3
>            Reporter: Stephen Mallette
>            Assignee: Stephen Mallette
>            Priority: Minor
>
> Not sure why it was explicitly blocked but there is validation that prevents 
> use of {{null}} as a property value for {{Map}} given to {{mergeV/E}}. That 
> validation should be removed because some graphs allow the storage of 
> {{null}} and the general Gremlin semantics for setting a property to {{null}} 
> for graphs that don't support storage is to remove the property. Removing the 
> validation will let {{mergeV/E}} adhere to those semantics. 



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

Reply via email to