Clarify behavior of MERGE on undirected relationships syntax. (#584)

Author: stefano-ottolenghi

modules/ROOT/pages/clauses/merge.adoc

@@ -328,8 +328,9 @@ Instead, a new `Movie` node is created.
 [[merge-merge-on-an-undirected-relationship]]
 === Merge on an undirected relationship
 
-`MERGE` can also be used with an undirected relationship.
-When it needs to create a new one, it will pick a direction.
+`MERGE` can also be used without specifying the direction of a relationship.
+Cypher will first try to xref:clauses/match.adoc#_match_on_an_undirected_relationship[match the relationship in both directions].
+If the relationship does not exist in either direction, it will create one left to right.
 
 .Query
 [source, cypher]
@@ -342,7 +343,7 @@ RETURN r
 ----
 
 As `'Charlie Sheen'` and `'Oliver Stone'` do not know each other in the example graph, this `MERGE` query will create a `KNOWS` relationship between them.
-The direction of the created relationship is arbitrary.
+The direction of the created relationship is left to right.
 
 .Result
 [role="queryresult",options="header",cols="1*<m"]
@@ -534,13 +535,13 @@ However, for relationship uniqueness constraints there are some additional thing
 
 For example, if there exists a relationship uniqueness constraint on `()-[:ACTED_IN(year)]-()`, then the following query,  in which not all nodes of the pattern are bound, would fail:
 
-.Query	
+.Query
 [source, cypher, role=test-fail]
 ----
 MERGE (charlie:Person {name: 'Charlie Sheen'})-[r:ACTED_IN {year: 1987}]->(wallStreet:Movie {title: 'Wall Street'})
 RETURN charlie.name, type(r), wallStreet.title
 ----
-	
+
 This is due to the all-or-nothing semantics of `MERGE`, which causes the query to fail if there exists a relationship with the given `year` property but there is no match for the full pattern.
 In this example, since no match was found for the pattern, `MERGE` will try to create the full pattern including a relationship with `{year: 1987}`, which will lead to constraint violation error.