Issue 1:
@SepiaGroup: 'Enhance the existing REST Unique API to support multiple indexes in one call: in reference to https://groups.google.com/forum/?fromgroups#!topic/neo4j/-YryBO8SkkI

http://localhost:7474/db/data/index/node/unique {

"indexes": [ {"index":"indexName1", "key": "uid", "value": "Tobias"},

{"index":"indexName2", "key": "email", "value": "Tobias@mail.com"}, ... ]

, "properties": {"name": "Tobias", "sequence"

: 1}}

would only be for unique indexes because wouldn't this call only be use for unique indexes regardless of how many index/key/value pairs were passed to it?

any other index updates would be called on another REST call as usual and not part of Unique transaction.

My thinking is that to ensure uniqueness you need to do the update to multiple indexes in one transaction and that is only possible (as far as i am aware of) over REST if the db does it.

Now thinking about the next step - updating: if you agree with the above then we would also need a way to update the index when required

http://localhost:7474/db/data/index/node/unique {

"indexes": [ {"index":"indexName1", "key": "uid", "value": "Tobias"},

{"index":"indexName2", "key": "email", "value": "Tobias@mail.com"}, ... ]

, "properties": {"name": "Tobias", "sequence"

: 1}

, "uri":"http://localhost:7474/db/data/node/116"}

would be the update call where uri points to the existing node, similar to

http://docs.neo4j.org/chunked/stable/rest-api-unique-indexes.html#rest-api-add-a-node-to-an-index-unless-a-node-already-exists-for-the-given-mapping

all index/key/value pairs would need to be checked against the key/values passed in the properties and if any duplicates are found the update fails for the entire call. Just like in sql if a key constraint is placed on a column in a table.

With this approach there is a very good chance that the index gets out of sync with the node properties (forget to add a index to the update call for example). maybe you can come up with some magic knowing the internals of the indexing better.

just my thoughts.

thanks'

Issue 2:
Neo4j Server version: 4.0.0 (community)

Operating system: Windows server 2012R2

API/Driver: Cypher console web browser (Neo4j Browser version: 4.0.1)

NOTE: Neo4j Browser version: 4.0.3/Neo4j Server version: 4.0.1 (community) (latest version as of right now) also exhibits the same behavior described below.

Load data

Run call db.schema.visualization()

The example DB at neo4j console: https://console.neo4j.org/r/nt3sgc

create (l1a:Level1 {name:'l1a'})
,(l1b:Level1 {name: 'l1b'})
,(l1c:Level1 {name: 'l1c'})
,(l1d:Level1 {name: 'l1d'})
,(l2a:Level2 {name: 'l2a'})
,(l2b:Level2 {name:'l2b'})
,(l3a:Level3 {name:'l3a'})
,(l1a)-[:OWNED_BY]->(l2a)
,(l1b)-[:OWNED_BY]->(l2a)
,(l1c)-[:OWNED_BY]->(l2b)
,(l1d)-[:OWNED_BY]->(l2b)
,(l2a)-[:OWNED_BY]->(l3a)
,(l2b)-[:OWNED_BY]->(l3a)
;

match (n1:Level1)-[:OWNED_BY]->(:Level1)
RETURN count(n1) as cnt, 'count_L1_to_L1' as description
UNION
match (n2:Level2)-[:OWNED_BY]->(:Level2)
RETURN count(n2) as cnt, 'count_L2_to_L2' as description
UNION
match (n3:Level3)-[:OWNED_BY]->(:Level3)
RETURN count(n3) as cnt, 'count_L3_to_L3' as description
UNION
match (n4:Level1)-[:OWNED_BY]->(:Level2)
RETURN count(n4) as cnt, 'count_L1_to_L2' as description
UNION
match (n5:Level2)-[:OWNED_BY]->(:Level3)
RETURN count(n5) as cnt, 'count_L2_to_L3' as description
;

call db.schema.visualization()

Here is the database contents as loaded. It's a simple tree type hierarchy where level 3 is the top node, and level 1 is the most detailed level. Each level's nodes points upward to a single parent, and there are no links across nodes in the same level.

The match query included above proves that there are relationships shown in the viz that do not exist in the DB.

Expected behavior

Viz should only show relationships between nodes where that type of relationship actually exists in the DB

Actual behavior

The viz shows inter-node links between ALL nodes that have the same relationship type instead of just those that actually exist in the DB.