{"action":"opened","issue":{"url":"https://api.github.com/repos/appscot/sails-orientdb/issues/131","labels_url":"https://api.github.com/repos/appscot/sails-orientdb/issues/131/labels{/name}","comments_url":"https://api.github.com/repos/appscot/sails-orientdb/issues/131/comments","events_url":"https://api.github.com/repos/appscot/sails-orientdb/issues/131/events","html_url":"https://github.com/appscot/sails-orientdb/issues/131","id":104332380,"number":131,"title":"Unexpected behavior and very slow query response, hence compromised functionality","user":{"login":"nidaca","id":12497736,"avatar_url":"https://avatars.githubusercontent.com/u/12497736?v=3","gravatar_id":"","url":"https://api.github.com/users/nidaca","html_url":"https://github.com/nidaca","followers_url":"https://api.github.com/users/nidaca/followers","following_url":"https://api.github.com/users/nidaca/following{/other_user}","gists_url":"https://api.github.com/users/nidaca/gists{/gist_id}","starred_url":"https://api.github.com/users/nidaca/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nidaca/subscriptions","organizations_url":"https://api.github.com/users/nidaca/orgs","repos_url":"https://api.github.com/users/nidaca/repos","events_url":"https://api.github.com/users/nidaca/events{/privacy}","received_events_url":"https://api.github.com/users/nidaca/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-09-01T18:58:41Z","updated_at":"2015-09-01T18:58:41Z","closed_at":null,"body":"Hello,\r\n\r\n   I have a very simple use case (from a large project): two models, model Person and model File, a simple one-way association between them, let's say 'avatar' (which is an optional attribute). So the waterline model of Person contains the definition of the association: { .... avatar: { model: 'file'; } ... }.\r\n\r\n   Now I make the following waterline query: Person.find( { key: 'value' } ).populate('avatar').exec(...), where the 'key' attribute is mapped to a string (indexed) field from the database, from class Person. For the previous query, the key needs to match a given input string value which leads to a record from the Person class with no associated avatar, meaning that the LINK property 'avatar' for this record has no value.\r\n\r\nThe problem is: two OrientDB queries are generated (taken from the debug console):\r\n\r\n- one for the initial find:\r\n        SELECT ..., avatar, ... FROM Person WHERE key='value'\r\n- and second:\r\n        SELECT ... FROM File WHERE @rid=:param0 ,\r\n    for the populate functionality ... This approach rise a first (implementation) question, is this second query really necessary ? Isn't the fetchplan approach a more suitable solution for populating the simple LINK's ?\r\n\r\nAnyway, this is not the main goal of this issue description:\r\n    For the above case scenario the execution of the waterline query will last forever (more than 6 SECONDS !!!). The problem seems to be that the last query receives a parameter with a 'null' value, which completely overwhelms the OrientDB database, I don't know why because it is a straightforward invalid usecase.\r\n    Shouldn't this null parameter be verified on the adapter side and removed from the query execution ? Thanks !"}}