Filtering bidirectional relationship in CRNK

822 Views Asked by At

I'm playing with crnk trying to deduce the bits I cannot find in the docs. I will explain my problem on standard crnk example: https://github.com/crnk-project/crnk-framework/tree/master/crnk-integration-examples/spring-boot-example.

There is one-to-many relationship between projects and tasks (the other resources are not relevant). If I understand it correctly (the example uses apparently deprecated opposite @JsonApiRelation parameter) the owner of the relation is 1Task.project1. I now want to list resources filtered by some properties of their related resources. E.g. this works as expected (leaving some unimportant bits from the response):

GET http://127.0.0.1:8080/api/tasks?filter[project.id]=121

{
  "data" : [ {
    "id" : "1",
    "type" : "tasks",
    "links" : {
      "self" : "http://127.0.0.1:8080/api/tasks/1"
    },
    "attributes" : {
      "name" : "Create tasks",
      "description" : null
    },
    "relationships" : {
      "project" : {
        "data" : {
          "id" : "121",
          "type" : "projects"
        }
    }
  } ]
}

But filtering in the opposite direction is not possible:

GET http://127.0.0.1:8080/api/projects?filter[tasks.id]=1

{
  "data" : [ ]
}

Is this expected under the setup of the resources (see above link)? If yes what must be done so that filtering works in both directions?

1

There are 1 best solutions below

4
Remo Meier On

Currently this is something a repository has to handle, one way of doing it is to make getter/setter become bidirectional, so a Task.setProject will add itself to Project.tasks.

IMHO I think it is something that a repository should handle, rather than built-in something in the crnk-engine. From a REST perspective an POST/PATCH/DELETE of a resource should NOT touch related resources. Which would defer the reponsitiblity to the repository to make those look-ups. But maybe there is a possiblity to have some built-in support for in-memory handling. The issue comes up with in-memory repositories. In for example the JPA case, SQL takes care of it (which could also provide a path of providing a solution to this).