Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
MuhammadTahaNaveed opened this issue Dec 27, 2023 · 7 comments · Fixed by #1516
Labels
bug Something isn't working

Comments

@MuhammadTahaNaveed
Copy link
Member

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 MuhammadTahaNaveed added the question Further information is requested label Dec 27, 2023
@MuhammadTahaNaveed MuhammadTahaNaveed added bug Something isn't working and removed question Further information is requested labels Jan 16, 2024
@MuhammadTahaNaveed
Copy link
Member Author

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
Copy link
Contributor

jrgemignani commented Jan 18, 2024

@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
Copy link
Member Author

MuhammadTahaNaveed commented Jan 18, 2024

@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
Copy link
Contributor

@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
Copy link
Member

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

@jrgemignani
Copy link
Contributor

@MuhammadTahaNaveed Can we close this issue?

@MuhammadTahaNaveed
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants