Custom filters sometimes work incorrectly for nested routes

Tái hiện request lồng nhau /authors/:id/books với cả bộ lọc title tích hợp sẵn và bộ lọc _title tùy chỉnh, sau đó theo dõi cách các lambda apply của bộ lọc tùy chỉnh nhận các record đối với các route lồng nhau. So sánh các điều kiện join ActiveRecord được tạo ra và thêm một regression test hoặc ghi lại yêu cầu về tên bảng, tùy thuộc vào hành vi dự kiến.

This issue is a (choose one):

• Problem/bug report.
• Feature request.
• Request for support. Note: Please try to avoid submitting issues for support requests. Use Gitter instead.

Checklist before submitting:

• I've searched for an existing issue.
• I've asked my question on Gitter and have not received a satisfactory answer.
• I've included a complete bug report template. This step helps us and allows us to see the bug without trying to reproduce the problem from your description. It helps you because you will frequently detect if it's a problem specific to your project.
• The feature I'm asking for is compliant with the JSON:API spec.

Description

Bug reports:

Gem version 0.10.5.

EDIT: After submitting this, I realized that this might not be considered a bug so much as a limitation due to how ActiveRecord joins work. It might be a good idea, however, to include a caveat in the documentation that table name must be specified in filters so as not to break join queries.

When using a custom filter (i.e. one defined with an apply lambda) on a nested route (/foos/:id/bars), the filter is applied on the parent model (Foo) instead of the child model (Bar), when the child model's table name is not specified in the filter query.

Example:

class AuthorResource < JSONAPI::Resource
  has_many :books
end

class BookResource < JSONAPI::Resource
  has_one :author 
  attributes :title

  filter :title

  filter :_title, apply: ->(records, value, _options){
    records.where(title: value)
  }
end

Rails returns the expected response for http://localhost:3000/authors/1/books?filter[title]=book1:

{"data":[
  {"id":"1",
   "type":"books",
   "links":{
    "self":"http://localhost:3000/books/1"
   },
   "attributes":{
     "title":"book1"
   },
   "relationships":{
     "author":{
       "links":{
         "self":"http://localhost:3000/books/1/relationships/author",
         "related":"http://localhost:3000/books/1/author"}}}}]}

But not for http://localhost:3000/authors/1/books?filter[_title]=book1

{"errors":[
  {"title":"Internal Server Error",
   "detail":"Internal Server Error",
   "code":"500",
   "status":"500",
   "meta":{
     "exception":"SQLite3::SQLException: no such column: authors.title",
     "backtrace":[...],
     "application_backtrace":[]}}]}

So, with filter[title], the filter is applied on Book, whereas with filter[_title], it is is instead applied on Author, in this case causing the error SQLite3::SQLException: no such column: authors.title, since the Author model does not have the attribute title.

filter[_title] does work, however, if we instead define it as:

  filter :_title, apply: ->(records, value, _options){
    records.where(books: {title: value})
  }

So I suppose applying the two versions of _title on records results in something like:

Author.joins(:books).where(title: 'book1')

and

Author.joins(:books).where(books: {title: 'book1'})

respectively, where the first one does not work as intended.