Not clear why JSON response receives an auto-generated key

[gabrielfior]

Describe the bug
When calling the method result = sg.query_json(), the returned object looks roughly like this:

$result
[{'xcfb7c9c5f581c978': [{"title":"title1", "id":1}, {"title":"title2",id":2}

It's not clear to me (also could not find anything in the docs) why the results are indexed by this (apparently random) key. Isn't it easier to just return all flattened items?
I apologize if this behaviour is documented somewhere.

To Reproduce

• Query this subgraph https://api.thegraph.com/subgraphs/name/protofire/omen-xdai/graphql?query=query+%7B%0A++fixedProductMarketMakers%28first%3A2%2C%0A++++where%3A+%7B%0A++++++outcomes%3A+%5B%22Yes%22%2C%22No%22%5D%0A++++%7D%0A++%29+%7B%0A++++id%0A++++outcomes%0A++%7D%0A%7D (fetching fixedProductMarketMakers)

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Python version (please complete the following information):

• 3.10.13

[0xMochan]

I can see how this might be a bit confusing. While this key seems a bit random, there is actually some purpose for this key (it's also not generated randomly).

A Subgrounds query is a bit more than the exact GraphQL it is replicating, it actually injects a bit of extra stuff to the query to help us sort through the response when organizing the output required by the main querying function query_df.

For example:

>>> url = "https://api.thegraph.com/subgraphs/name/protofire/omen-xdai"
>>> with Subgrounds() as sg:
...     subgraph = sg.load_subgraph(url)
...     field = subgraph.Query.fixedProductMarketMakers(
...          first=2,
...          where={"outcomes": ["Yes", "No"]}  # using relative form
...     )
...     request = sg.make_request([field.id, field.outcomes])
>>> print(request.graphql)

query {
  x8b50aedfc3bfeb1f: fixedProductMarketMakers(first: 2, where: {outcomes: ["Yes", "No"]}) {
    id
    outcomes
  }
}

While this query seems to match up with the GraphQL API link you posted, Subgrounds actually injected some extra data (starting with x8b..). This is the name of the query, autogenerated as a hash of the fields and conditions of the top-level entity, fixedProductMarketMakers, being queried. Since Subgrounds allows you to stack multiple queries to the same top-level entity in the same query, there needs to be some way to be able to identify the same field that might have different conditions. Here is an example of this situation.

>>> with Subgrounds() as sg:
...     subgraph = sg.load_api(url)
...     yes = subgraph.Query.fixedProductMarketMakers(first=2, where={"outcomes": ["yes"]})
...     no = subgraph.Query.fixedProductMarketMakers(first=2, where={"outcomes": ["no"]})
...     request = sg.make_request([yes.id, yes.outcomes, no.id, no.outcomes])
>>> print(request.graphql)

query {
  xe6482a7b42808c65: fixedProductMarketMakers(first: 2, where: {outcomes: ["yes"]}) {
    id
    outcomes
  }
  x626d33e4fd087f66: fixedProductMarketMakers(first: 2, where: {outcomes: ["no"]}) {
    id
    outcomes
  }
}

---

This is a bit of a more thorough breakdown to explain this behavior but the true resolution to this is actually more of an interface design POV. When the query_* interface was first designed, it was centered around query and query_df and query_json was actually more of an internal method used as the "raw" handler of the json of The Graph response. This is likely a mistake but something the current API lives with since we don't want to introduce breaking changes. Ideally, query_json would strip this extraneous information (or at least rename it to something human readable).

I realize there's not an issue for this currently, but there have been ideas internally about a more fleshed out / updated API interface for the Subgrounds query method that would be a bit more flexible, allowing for a better JSON output amongst other forms of output. LMK if you have more questions about this, hope this explains it well 👍