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

Silent failure when incorrectly querying for edges #5446

Closed
lodrion opened this issue Dec 10, 2015 · 3 comments
Closed

Silent failure when incorrectly querying for edges #5446

lodrion opened this issue Dec 10, 2015 · 3 comments
Assignees
Labels

Comments

@lodrion
Copy link

lodrion commented Dec 10, 2015

SELECT EXPAND( inE(MyEdgeName) ) FROM #62:4 limit -1
does not fail, but instead returns ALL of incoming edges

quoting the name, on the other hand produces the correct results
SELECT EXPAND( inE("MyEdgeName") ) FROM #62:4 limit -1

@lvca lvca added this to the 2.1.x (next hotfix) milestone Dec 10, 2015
@lvca lvca assigned lvca and unassigned luigidellaquila Dec 10, 2015
@lvca
Copy link
Member

lvca commented Dec 10, 2015

MyEdgeName is replaced with the field with name MyEdgeName, but since it doesn't exist, it's null. inE(null) means get all the incoming edges, so it's correct.

@lvca lvca closed this as completed Dec 10, 2015
@lvca lvca removed this from the 2.1.x (next hotfix) milestone Dec 10, 2015
@lodrion
Copy link
Author

lodrion commented Dec 10, 2015

Is there any way to detect these cases (some kind of strict mode)? While this is technically correct, it can (and does) lead to hard to find bugs.

The existing strict mode is a reverse of this -- it makes all fields required. What I want is requests for fields that are not in the schema to fail

@luigidellaquila
Copy link
Member

Hi @lodrion

I'm afraid there is no automatic way to check it. Strict mode checks schema only during insert/update operations.

Thanks

Luigi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants