Proposal: Additional query support

Questions & Feedback
1

Hi @adamfuller

As we are going through different use cases for building analytics applications on The Graph, we are running into some limitations on the queries currently provided. We’d like to be able to do something like:

  1. Filtering data by nested field
{
  deposits( where: {reserve:{symbol:"DAI"}}) {
    reserve {
      symbol
    }
    amount
    timestamp
  }
}
  1. Sorting data by nested field
{
  deposits(
    orderBy:reserve.symbol
  ) {
    reserve {
      symbol
    }
    amount
    timestamp
  }
}
  1. Sorting data by multiple fields
{
  deposits(
    orderBy:timestamp
    orderDirection:asc
    orderBy:amount
    orderDirection:desc
  ) {
    reserve {
      symbol
    }
    amount
    timestamp
  }
}
  1. Grouping data by different fields.
  2. Math, string and array operators
3 Likes
2

Hi @huangkuan! Thanks, these are great ideas - we are hoping to improve the query planner (1,2,3), and Grouping data is definitely important for analytics use cases.
Can you give a bit more detail on what you mean by Math, string and array operators?

3 Likes
3

1,2,3 are definitely more important. The sooner this can be solved, the sooner we can rely less on an intermediate data layer.

Using the below data structure as an example:

{
  deposits( where: {reserve:{symbol:"DAI"}}) {
    reserve {
      symbol
    }
    amount
    timestamp
  }
}

A. amount stores the amount of tokens in 18 decimals. When I am displaying this value in a table, I want to get rid of the decimals. That would require a “divide” operator.

B. I want to be able to display amount and symbol in one field. That would require a string appending operator that connects both strings.

4

1, 2, and 3 seem like great additions.

For 4 and 5 I think a client-side solution is preferable. There is almost no end to the kinds of data formatting and pre-processing that one would like to be able to do and pushing all of those to the server is an exercise in futility. The turnaround for a new formatting option to be pushed through the protocol would very high (months?), and there are established patterns for displaying formatted data on the client which can be tested in minutes instead.

It’s been a while since I used WPF or React, but the way that one would normally achieve this would be to have a custom component that rendered the data binding in a particular way. Here are some examples: Formatting dates and numbers in React | Building SPAs

1 Like
6

I’m not sure I agree in general. Any kind of aggregation should be done server-side. For example, say I have this entity:

type Price @entity {
  id: ID!
  timestamp: BigInt!
  priceReturnA: BigDecimal!
  priceReturnB: BigDecimal!
}

and say this entity has 10GB worth of data. Now, say I want the correlation between priceReturnA and priceReturnB. The only sensible approach would be to compute the correlation on the server and send the result to the client.

See: Postgres

7

That sounds pretty contrived.