Update type names of IGSDB V2

[christoph-maurer]

In version 2, the IGSDB uses different type names than specified in database.graphql. For example, the query allData in the IGSDB has ProductTypeConnection as return type, whereas it is DataConnection in database.graphql. This is no problem, when types are not used in queries as in your example above. However, the actual query mentioned in https://github.com/building-envelope-data/metabase/issues/142#issuecomment-1420802604 uses the fragment fragment DataFields on Data { ... }. This fragment does not work on the IGSDB, because the type Data does not exist there. The corresponding type has the name ProductType.

Originally posted by @simon-wacker in https://github.com/building-envelope-data/metabase/issues/142#issuecomment-2045167261

[christoph-maurer]

@danielmcquillen Is it difficult for you to update the type names?

[danielmcquillen]

@christoph-maurer @RDmitchell This gets into the "strawberry" library used to implement the API. We can look into it but it's probs not a simple change...

[christoph-maurer]

@danielmcquillen Did you find a way how to deal with the type names? Currently, IGSDB and the product data network don't work together. This issue has therefore a much higher priority for me than my other issues.

[danielmcquillen]

@christoph-maurer @RDmitchell

I'm a bit confused on this one, because the example query you're pointing too is more complex than the 'basic' queries we support for GraphQL as part of our first, test implementation. (Those basic queries are documented here: http://igsdb-v2.herokuapp.com/docs/help/using-api/graphql)

The query you're pointing to is more involved, as it include a number of features of an advanced GraphQL query that I'm not sure our current implementation can support.

However, I was able to at least resolve ( I think ) the 'type' issue, with the GraphQL API now delivering a 'DataType' instead of a 'ProductType' for products, such that the following query will now work:

fragment DataFields on DataType {
  componentId
}

query {
    allData {
    edges {
      node {
        __typename
        ...DataFields
      }
    }
  }
}

Perhaps you can see how much this helps in terms of supporting your more complex queries?

[christoph-maurer]

@danielmcquillen In the medium run, it is important to implement the API specification fully. In the short run, we remove the fragments in the query to IGSDB.

[RDmitchell]

@christoph-maurer -- it is not clear to me that we will be able to implement the full GraphQL functionality in SEED that you require. We will add something about this to our FY 2025 budget request, but can't guarantee that we will be able to fund this.