Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem when trying to query both sides of many-to-many relationship #454

Open
Lezek123 opened this issue Sep 2, 2021 · 1 comment
Open
Assignees
Labels
bug Something isn't working estimate-9h 9h task low-prio

Comments

@Lezek123
Copy link
Contributor

Lezek123 commented Sep 2, 2021

I'm running into an issue when trying to query both sides of a many-to-many relationship.
This happens both on version 3.1.0-alpha.1 and 3.1.0-alpha.9 (with the most recent #453 fixes)

Setup:

  • Checkout Distributor node joystream#2582
  • Update Hydra dependencies in query-node workspace
  • docker-compose build joystream-node
  • docker-compose up -d joystream-node
  • yarn && yarn workspace @joystream/types build && yarn workspace @joystream/metadata-protobuf build && yarn workspace query-node-root build
  • ./query-node/start.sh
  • ./distributor-node/scripts/test-commands.sh

Example query:

query {
  distributionBuckets {
    id
    distributedBags {
      id
    }
  }
  storageBags {
    id
    distributedBy {
      id
    }
  }
}

Expected result:

{
  "data": {
    "distributionBuckets": [
      {
        "id": "0",
        "distributedBags": [
          {
            "id": "CO"
          }
        ]
      }
    ],
    "storageBags": [
      {
        "id": "CO",
        "distributedBy": [
           {
              "id": "0"
            }
         ]
      }
    ]
  }
}

Actual result:

{
  "data": {
    "distributionBuckets": [
      {
        "id": "0",
        "distributedBags": [
          {
            "id": "CO"
          }
        ]
      }
    ],
    "storageBags": [
      {
        "id": "CO",
        "distributedBy": []
      }
    ]
  }
}

As you can see, storageBags->distributedBy returns empty set, even though it's just the owning side of distributionBuckets->distributedBags many-to-many relationship, as defined by the schema:

type DistributionBucket @entity {
  "Runtime bucket id"
  id: ID!

  # ...

  "Bags assigned to be distributed by the bucket"
  distributedBags: [StorageBag!] @derivedFrom(field: "distributedBy")
}

type StorageBag @entity {
  "Storage bag id"
  id: ID!

  # ...

  "Distribution buckets assigned to distribute the bag"
  distributedBy: [DistributionBucket!]
}

Other observations:

There is a distribution_bucket_storage_bag (notice the inverse side table name goes first) table generated in the procesor database in order to support distributionBucket->storageBag many-to-many relationship. For storageBucket->storageBag the table name is storage_bag_storage_bucket (notice the owning side table name goes first). For some reason this turns out to be inline with which side of the relationship is available when querying, so:

  • storageBuckets->storedBags doesn't work (returns empty set)
  • storageBags->storedBy works
  • distributionBuckets->distributedBags works (as shown above)
  • storageBags->distributedBy doesn't work (empty set)
@ondratra
Copy link
Contributor

I inspected the problem when working on relation filtering as it seemed related. It appears that the problem is not in the code of Hydra or Warthog, but rather somewhere deeper (Apollo server mb?). The first query finding storageBags originates in our code and seems to work fine. After that, a query (or queries) that tries to find the related objects generates valid SQL as seen in the console but fails to return a valid result to the graphql server. Maybe the problem is with mapping SQL results to typeorm object - naming of columns return by SQL query is different than what is expected by typeorm(?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working estimate-9h 9h task low-prio
Projects
None yet
Development

No branches or pull requests

3 participants