Usage of containment op instead of equal in property constraints (for lists and maps)

[MuhammadTahaNaveed]

Usage of containment op instead of equal in property constraints (for lists and maps) outputs different results as compared to neo4j. Is this intentional?

Data:

CREATE (n {list:[1,2,3,4]}) return n

Query with issue:

MATCH (n {list:[4]}) return n

Results

Neo4j:

No rows returned

Age:

pg16=# SELECT * FROM cypher('issue_', $$MATCH (n {list:[4]}) return n$$) AS (u agtype);
                                         u                                          
------------------------------------------------------------------------------------
 {"id": 281474976710657, "label": "", "properties": {"list": [1, 2, 3, 4]}}::vertex
(1 row)

[MuhammadTahaNaveed]

Hi guys,

I have a question on this issue. For list as property, I was able to cross check the output using neo4j. But neo4j doesnt allow map as a property in an entity, so I wasn't able to check the expected behavior for that scenario.

So I wanted to know what should we do in this case. The scenario is explained in the example below.

CREATE (x:Customer {
    name: 'Bob',
    school: {
        name: 'XYZ College',
        program: {
            major: 'Psyc',
            degree: 'BSc'
        }
    }
})

Currently it does not perform equality check on the value if it is a map, rather performs a containment check.

issue_1461=# SELECT * FROM cypher('issue_1461', $$MATCH (x:Customer {
    school: {
        name: 'XYZ College'
    }
}) return x$$) as (a agtype);
                                                                                   a                                                                                   
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 {"id": 844424930131969, "label": "Customer", "properties": {"name": "Bob", "school": {"name": "XYZ College", "program": {"major": "Psyc", "degree": "BSc"}}}}::vertex
(1 row)

Should it be what it is currently? or like lists, it should do an equality check on property.school i.e

property.school = {"name": "XYZ College", "program": {"major": "Psyc", "degree": "BSc"}}

[jrgemignani]

@MuhammadTahaNaveed I feel like this could be argued either way, if I understand the question.

When someone is looking for, SELECT or MATCH, they're asking if something has this something. It could be, does it have it or does it equal it. But, it ends up being a bit ambiguous as to what is wanted.

Maybe we should have a default behavior, say contains, and an operator to modify that behavior?

For example,

Contains as default, equals when specified -

        MATCH (x:Customer {school: {name: 'XYZ College'}}) return x
        MATCH (x:Customer ={school: {name: 'XYZ College'}}) return x

Equals as default, contains when specified -

        MATCH (x:Customer {school: {name: 'XYZ College'}}) return x
        MATCH (x:Customer ~{school: {name: 'XYZ College'}}) return x

I say a default contains because it feels like when doing a SELECT or MATCH you are asking for all occurrences and then, by using qualifiers, you are narrowing the results down.

Just my thoughts

[MuhammadTahaNaveed]

@jrgemignani

Contains as default, equals when specified -

        MATCH (x:Customer {school: {name: 'XYZ College'}}) return x
        MATCH (x:Customer ={school: {name: 'XYZ College'}}) return x

Sounds good to me. Just to clarify though, this should be for both lists and maps occurring as property values or just maps? Because if we take the example below in case of list as property value

CREATE (x:Customer {
    addr: [
        {city: 'Vancouver', street: 30},
        {city: 'Toronto', street: 40}
    ]
}

Now the query below returning the row(by default) makes sense to me, keeping in mind

when doing a SELECT or MATCH you are asking for all occurrences and then, by using qualifiers, you are narrowing the results down.

MATCH (x:Customer addr:[{city: 'Vancouver'}]) RETURN x

What do you think?

[jrgemignani]

@MuhammadTahaNaveed We definitely need to discuss this because lists and maps can be embedded in each other. It would seem to be best to apply the same logic to both.

[rafsun42]

I agree that it should apply to both nested maps and lists.

[jrgemignani]

@MuhammadTahaNaveed Can we close this issue?

[MuhammadTahaNaveed]

@jrgemignani This issue was resolved in #1516. I am going ahead with closing this issue.