Loopback: Include filter has stopped working for hasMany through relationships

[matthewdickinson]

This week, I updated my dev copy of my project to use the newest loopback packages. I noticed later that some of the include filters have stopped working. However, using the direct api/Model/:id/relation endpoint still returns the data I expect.

Here is the link to my test repo (I noticed the issue while using the mysql connector, but during debugging found that is also occurs using the in memory db) : https://github.com/matthewdickinson/loopback-sandbox

Steps to Reproduce:
(Using explorer)
Create new Customer:

{
  "id": 1,
  "firstname": "Test"
}

Create a new Group

{
  "id": 1,
  "name": "Test Group"
}

Create a new CustomerGroup

{
  "id": 1,
  "groupId": 1,
  "customerId": 1
}

View groups for Customer 1:
http://localhost:3000/api/Customers/1/groups

[{"id":1,"name":"Test Group"}]

Try to lookup the customer and include the groups:
http://localhost:3000/api/Customers?filter[where][id]=1&filter[include]=groups
OR
http://localhost:3000/api/Customers?filter[include]=groups

[{"id":1,"firstname":"Test","groups":[]}]

Expected output: [{"id":1,"firstname":"Test","groups":[{"id":1,"name":"Test Group"}]}]

However, include itself if not broken. This URL http://localhost:3000/api/CustomerGroups?filter[include]=groups still returns the expected results

[{"id":1,"groupId":1,"customerId":1,"groups":{"id":1,"name":"Test Group"}}]

[raymondfeng]

@superkhau Can you look into it?

[superkhau]

@raymondfeng Sure.

@chandadharap Can you prioritize this during sprint planning?

[scottp]

I can confirm I have the same problem using my own system. Filters work, hasMany works, but hasMany through (many to many relationships) do not work.They either return all rows, or never returns.

[superkhau]

@matthewdickinson @scottp I don't see any issues. Check my sample repo here: https://github.com/superkhau/sandbox/tree/bug/1566. You can run the requests via the included ./send-request script. Are you guys creating your model relations correctly?

[superkhau]

Closing as there has been no response in awhile. Re-open if you guys are still running into issues.

[matthewdickinson]

I believe that I have found why I still have an issue and you don't: from my tests, Loopback no longer handles models which have plural model names -- when my model files were generated, they came pre-pluralized (e.g. my model is Customers instead of Customer). When I converted these modules to use singular model names, then the tests outlined work fine. However, in previous versions of Loopback, singular-ly named model were handled fine. Was this an intentional change? If not, then I believe this bug should remain open.

I pushed updates to the repository listed above -- the non-working version is still in the master branch, while the working version is in the name_changes branch (identical except for model names).

[matthewdickinson]

I replied to this issue (with more details) requesting it be re-opened, but
nothing seemed to happen.

On Tue, Sep 29, 2015 at 4:00 PM Simon Ho [email protected] wrote:

Closed #1566 https://github.com/strongloop/loopback/issues/1566.

—
Reply to this email directly or view it on GitHub
https://github.com/strongloop/loopback/issues/1566#event-422321412.

[superkhau]

@matthewdickinson Sorry for the late response, I've reopened the issue. I will try to reproduce it with your updates.

In the meantime, @raymondfeng Do you know anything about this breaking change off the top of your head?

[GaryTowers]

Same issue happening for me.
When I try to get my items with an include of another in them (and the relation is hasMany with through) it returns an empty array.

LivingArea hasMany CommonAreas through LivingCommonAreas

[GET] /livingAreas/?filter[include]=commonAreas
This returns all my LivingAreas with an array of commonAreas, however the array is empty every time even though there is related data.

[GET] /livingAreas/1/commonAreas
This returns an array of commonAreas for the livingArea 1 showing that indeed the relation exists.

Any idea on how to approach this?

[matthewdickinson]

I've looked through the code, and I think I've found the cause of this issue. In the relationship setup code (https://github.com/strongloop/loopback-datasource-juggler/blob/master/lib/relation-definition.js#L589), the it sets a property keyThrough to use for lookup values. If this property is not in the relationship definition in the .json file, it uses the model name (which in my and @GaryTowers case is plural) -- this generates a bad ID. However, if the model definition JSON file contains the keyThrough then everything appears to work correctly.

It looks like the confusion came from the fact that the documentation for this property was not added until Aug 12, 2015. (https://docs.strongloop.com/pages/diffpages.action?originalId=6722359&pageId=6722362)

If my understanding of the function of this property is correct, then I believe that this has now been resolved.

I've pushed the update that makes my code work to the repo listed above.