Include with filter does not filter out where condition

[sneakersgames]

Following the documentation as regarding scope on include filter: https://loopback.io/doc/en/lb3/Include-filter.html

 Spot.find({
       include: {
         relation: 'categories', // include the categories object
         scope: { // further filter the categories object
           where: {categoryId: 45} // only select category with id 45
         }
       }
     }, function(err, Spots) {
       /* ... */
       console.log(Spots);
       cb(null, Spots);
     });

Gives me an array with Spots without categoryId 45:

I would expect this object isn't returned since it doesn't have categoryId 45

spot.json

{
  "name": "Spot",
  "plural": "spots",
  "base": "PersistedModel",
  "idInjection": true,
  "options": {
    "validateUpsert": true
  },
  "properties": {
    "name": {
      "type": "string",
      "required": true
    },
    "location": {
      "type": "GeoPoint",
      "required": false
    },
...
  },
  "validations": [],
  "relations": {
    "categories": {
      "type": "hasAndBelongsToMany",
      "model": "Category",
      "foreignKey": ""
    },
...
  },
  "acls": [],
  "methods": {}
}

category.json

{
  "name": "Category",
  "plural": "categories",
  "base": "PersistedModel",
  "idInjection": true,
  "options": {
    "validateUpsert": true
  },
  "properties": {
    "name": {
      "type": "string",
      "required": true
    }
  },
  "validations": [],
  "relations": {
    "spots": {
      "type": "hasAndBelongsToMany",
      "model": "Spot",
      "foreignKey": ""
    }
  },
  "acls": [],
  "methods": {}
}

[0candy]

Do you have a model that links those two models together?
See https://loopback.io/doc/en/lb2/HasAndBelongsToMany-relations.html#defining-a-hasandbelongstomany-relation

It would help if you could create a sample repo so I can reproduce the exact issue you are seeing.
http://loopback.io/doc/en/contrib/Reporting-issues.html#bug-report

[necevil]

I actually think I may be in a similar boat on this one.
@sneakersgames in my instance I am matching any property name (in any one of my models) to any possible value and returning every instance of the model as a result.

I need to re-structure the project to provide a sample repo, but in the interim, try enterying a vald but crazy query in the loopback explorer. For instance, every one of my models will match based on the clearly nonsen

{"adsfafda": "adsfklhasglhk"}

Since I thought that was crazy, I can then copy and paste any of the returned propterties / values (that come back as the response to the above Loopback Explorer Query) back into the filter field (where that property / value DOES NOT match more than one instance, but does match exactly one instance) and yet again it returns all instances of the model.

Might be worth trying to reproduce that behavior in your case to see if we are on the same page.

I burnt myself out on this one over the past couple of hours so I am going to put it down and pick it back up tomorrow. My thinking is that it has to be something with the model names / relationships since I have been by hand editing my model.json files.

I think what I will do tomorrow is attempt to re-create the models using the CLI and see if I can get around the issue / find the bug in my JSON that way. I think that it presented itself around the time I added a second belongsToOne relationship to a single model.

ie. Date Belongs to One Trip, Belongs to One Deal in my case.

[necevil]

My filters, both Node Syntax and Rest Syntax (through Loopback Explorer) are still failing to filter data appropriately.

Updates since Yesterday:

1. Have tested WHERE filters on simultaneously connected MySQL and MongoDB datasources (different models): All Datasources experience the issue although I am not using any In-Memory DB sources.
2. Tested FindById Loopback Default Remote method: findById works as intended and properly filters / returns only the specify model instance that matches the Id passed, even though creating a Filter that would match only the Model ID does not work and returns all instances.
3. Tested Count Loopback Default Remote method: Count properly returns the number of posts using the supplied Filter, ie. 1 for Post Id 88 for example.
4. Since I know sometimes the model definitions can differ from the Models on the datasources I added Auto-Update to a boot script. I had to do this originally to make my Loopback instance connect / sync to the backend of my Ghost Blog, so really I just added Auto-Update for the models that I store in the separate MongoDB datasource: No Auto-Update necessary for MongoDB datasource models.
5. Renamed Model that was created around the first time the Bug / Behavior was experienced from "Date" to "FlightDate" in order to avoid conflicting with potential name-scape objects: No effect, bug / behavior persists.
6. Removed all authentication to make sure that is not an issue: No effect, bug / behavior persists.

Next steps:

1. Move one of the models to In-Memory to test to see if this changes things (not that this is a potential solution, but could potentially help isolate things)
2. FORK Loopback-sandbox and Re-create the loopback project, models and relationships to see if my manual editing of the Model JSON files is the culprit (as mentioned in my last comment).
3. Create a WHERE filter using something other than EQUALS to compare values to see if this has different behavior.

Continuing to trouble shoot my issue.
Will post as I have more results.

In reference to the OP issue, I am posting here only because my Filters are also not working. I do not use hasAndBelongsToMany.

[necevil]

Update from Yesterday:

1. Move one of the models to In-Memory to test to see if this changes things (not that this is a potential solution, but could potentially help isolate things)
2. Create a WHERE filter using something other than EQUALS to compare values to see if this has different behavior. Result: Filters still do not work, regardless of the operand used.

Most importantly:
3. FORK Loopback-sandbox and Re-create the loopback project, models and relationships to see if my manual editing of the Model JSON files is the culprit (as mentioned in my last comment).

Result: After cloning, doing NPM install, and prior to moving ANY of my code / models over, I created a single test model and tested Filters against that model in the base loopback-sandbox repo.

The bug presented it's self within my Docker Alpine Loopback Container with none of my code / models. Therefore I exited Docker and ran without Virtualization on OSX. The Bug persisted.

At this point it is safe to say that either it is an issue with my OS / variables that is some how passed through from my host, or vice versa (which to my knowledge would be difficult or impossible) or that this is a bug in loopback that came about related to a breaking dependency update that happened recently.

I did recently (prior to experiencing the Filters bug for the first time) add both Lodash and Async to to my project.

My guess is that when I installed either the Async module, or alternately Lodash (neither of which existed in my project prior to this issue presenting itself) then one of those packages updated one of the dependencies that is shared by both Loopback AND the offending module.

Since the breaking co-dependency change was the latest version of whatever that co-dependency requires, when I then cloned the loopback-sandbox and did an NPM install I believe it would also pull this latest version and therefore also does not work.

Moving toward filing a full bug report / opening a new issue.

[necevil]

@0candy @sneakersgames
After cloning Loopback-sandbox and experiencing my issue, I have opened a new ticket since my issue is not related to INCLUDE filters (even though it could be related to this one) issue: #3372

I was able to reproduce on two OSes using the sandbox repo with no-changes.