ynput / ayon-python-api

Apache License 2.0
8 stars 3 forks source link

Easier nested fields on representation #141

Closed iLLiCiTiT closed 4 months ago

iLLiCiTiT commented 4 months ago

Description

Auto expand "files" field on representation to it's nested fields.

BigRoy commented 4 months ago

Could you explain to me why this is needed? Why do we need to auto-expand?

Usually it should mean that files as a field means 'include anything in files'. What makes files special that we need this extra care? I feel like by expanding the query is now "heavier" because we're submitting more data with the query call.

BigRoy commented 4 months ago

I feel like this issue may be at the backend because this PR https://github.com/ynput/ayon-python-api/pull/138 seems to suffer as well. Why do we need to expand these fields?

I'd expect a query like fields={"attrib"} to mean, attrib and any of its content - and it's the same with the others. I don't understand why we need to expand these in the query itself? Is there an issue with the actual backend that we're trying to workaround?

iLLiCiTiT commented 4 months ago

I feel like this issue may be at the backend because this PR https://github.com/ynput/ayon-python-api/pull/138 seems to suffer as well. Why do we need to expand these fields?

I'd expect a query like fields={"attrib"} to mean, attrib and any of its content - and it's the same with the others. I don't understand why we need to expand these in the query itself? Is there an issue with the actual backend that we're trying to workaround?

Well, backend is in this case ayon-python-api. All these methods are using GraphQl to get only specific fields or to get multiple entities at the same time. REST endpoints will always return all the data, but when graphql is used you must enter the graphql query... The attribute fields is just expanded into the graphql, and because some fields are nested then we have to be explicit about the sub-fields we want to get.

query MyQuery {
  project(name: "someProjectName") {
    representations {
      edges {
        node {
          files {
            hash
            hashType
            id
            name
            path
            size
          }
        }
      }
    }
  }
}
BigRoy commented 4 months ago

Well, backend is in this case ayon-python-api. All these methods are using GraphQl to get only specific fields or to get multiple entities at the same time. REST endpoints will always return all the data, but when graphql is used you must enter the graphql query... The attribute fields is just expanded into the graphql, and because some fields are nested then we have to be explicit about the sub-fields we want to get.

Interesting - so graphql is unable to just retrieve the files in its complete state using something like * or alike? According to this GraphQL requires to be explicit and thus this is required for that to work.

I guess it's an unfortunate side effect of how GraphQL works. I do know that when calling it from the ayon_api I would never expect it to lack any subfields, which kind of feels like we now might need to ensure that at least the 'defaults' we expand to as subfields are actually at all times all the subfields? (Maybe requiring a test-suite, etc.?)