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

Easier nested fields on representation #141

Merged
merged 1 commit into from
Apr 16, 2024

Conversation

iLLiCiTiT
Copy link
Member

Description

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

@iLLiCiTiT iLLiCiTiT merged commit e98040c into develop Apr 16, 2024
@iLLiCiTiT iLLiCiTiT deleted the enhancement/add-representation-files-fields branch April 16, 2024 13:58
@BigRoy
Copy link

BigRoy commented Apr 16, 2024

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
Copy link

BigRoy commented Apr 16, 2024

I feel like this issue may be at the backend because this PR #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
Copy link
Member Author

iLLiCiTiT commented Apr 16, 2024

I feel like this issue may be at the backend because this PR #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
Copy link

BigRoy commented Apr 16, 2024

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.?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants