Check for exists/not exists property return error

[mrbatista]

Description/Steps to reproduce

After download app sandbox: npm install && npm test

Link to reproduction sandbox

https://github.com/mrbatista/loopback-sandbox/tree/bug/coerce-date-filter-exists

Expected result

When check for property defined as type Date the response is Error: Invalid date: [object Object]. The workaround at the moment is to declare property with type any (it's actually a date). See property created defined in Message model.

[jdhrivas]

@mitsos1os make sure you set "allowExtendedOperators": true in your mongo datasource.json file.

[bajtos]

@mrbatista sorry for the long silence on our side.

AFAIK, strong-remoting 3.x no longer coerces deep properties. Could you please post a full stack trace of the error you are encountering and provide us steps how to reproduce the problem using your sandbox app?

[mrbatista]

@bajtos find the link and step to reproduce problem on my first post. 😕

[bajtos]

@mrbatista sorry, I didn't realize that you created a test that fails in your sandbox. When I cloned your sandbox app, started a MongoDB server and executed npm test, I received the following test failure:

  1) Filter with exists clause
       should filter data with deleted property - date type:
     AssertionError: expected { Object (statusCode, message) } to be undefined
      at Context.it (test/filter-exists-date-property.test.js:13:33)
      at process._tickCallback (internal/process/next_tick.js:68:7)

Is that the reproduction of the problem you are facing?

[mrbatista]

@bajtos yes!

[bajtos]

Sorry for the delay, I'll try to find some time next week to look into this issue.

[bajtos]

@mrbatista I debugged your example app and this is what I found:

1. exists is not a built-in operator, it's MongoDB specific.

2. To use a database-specific operator, you need to prefix it with $, e.g. $exists.

   const filter = JSON.stringify({where: {deleted: {$exists: true}}});

3. By default, database-specific operators are not allowed. You need to enable this feature via model settings (on a per-model basis) or datasource settings (for all models attached to the datasource).

   {
     "name": "Message",
     "base": "PersistedModel",
     "idInjection": true,
     "options": {
       "validateUpsert": true,
       "allowExtendedOperators": true
     },
     // etc.
   }

With these two changes in place, both of your tests are passing for me.

I wish loopback-datasource-juggler was failing with a more helpful error, and/or our documentation was better in explaining how to use extended operators. If you have any ideas on how to improve this area, then a pull request would be highly appreciated!