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

Null and NotNull where conditions not supported #17

Open
jkeczan opened this issue Oct 16, 2015 · 4 comments
Open

Null and NotNull where conditions not supported #17

jkeczan opened this issue Oct 16, 2015 · 4 comments
Labels

Comments

@jkeczan
Copy link

jkeczan commented Oct 16, 2015

When testing query using where clause with either 'null' or 'notNull' conditions specified, an error occurs.

Code:

Userreset.findOne({
                        where: {
                            "userID": '12345',
                            "dateUsed": {
                                "notNull": true
                            }
                        }
                    })

Error:

[TypeError: undefined is not a function]
Error (E_UNKNOWN) :: Encountered an unexpected error
TypeError: undefined is not a function
    at Object.module.exports.adapter._applyQueryFilter (/project/node_modules/sails-dynamodb/index.js:691:47)
    at Object.module.exports.adapter.find (/project/node_modules/sails-dynamodb/index.js:594:41)
    at module.exports.find (/usr/local/lib/node_modules/sails/node_modules/waterline/lib/waterline/adapter/dql.js:120:13)

Are these intentionally no longer supported? If so, can we update the documentation, as it can be misleading?

@devinivy
Copy link
Collaborator

It should be supported– this is a bug. Will take a PR.

@devinivy devinivy added the bug label Oct 16, 2015
@jkeczan
Copy link
Author

jkeczan commented Oct 16, 2015

After further research, the not null and null are supported; however, they are only supported for scans, not for index queries. With that in mind, I believe that the indexes are being improperly chosen. For example, if you pass through the primary hash and a non-index based column, it will STILL try to use the primary index which results in error.

The solution is to confirm that all columns passed through the where clause are actually apart of an index. If they are not, then a scan should be performed instead.

@devinivy
Copy link
Collaborator

Ah, you're probably right. I'm pretty sure that should be detected right around here:

@jkeczan
Copy link
Author

jkeczan commented Oct 16, 2015

We agree as well. We don't have the time to push a PR right now so we wanted to get all of the info here for anybody else.

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

No branches or pull requests

2 participants