query historical data by block range - initial changes (#1887)

[abhishek818]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes #1887

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist

• I have tested locally
• I have performed a self review of my changes
• Updated any relevant documentation
• Linked to any relevant issues
• I have added tests relevant to my changes
• Any dependent changes have been merged and published in downstream modules
• My code is up to date with the base branch
• I have updated relevant changelogs. We suggest using chan

[abhishek818]

@stwiname

Hey, can you give this PR changes a brief look, I will get time to work on this only during coming weekend AND I might get some queries about the requirements when nobody online will be around,
So just wanted to see if this is going in right direction?

Queries of below type is implemented currently (perhaps partially).

query {
        items(blockRange: [0, 100]) {

.

Further we need below types also right ??

query {
        items(blockHeight: {
                                      lessThan/lessThanOrEqualTo/greaterThan/greaterThanOrEqualTo : <value>
                                      }
                 ) {

.

What further requirements/any sample responses/queries expected to cover are needed do tell, thanks..

[stwiname]

Hey @abhishek818

I think this is fine

query {
        items(blockRange: [0, 100]) {

As for the other case I think we could drop lessThan/lessThanOrEqualTo/greaterThan/greaterThanOrEqualTo as we could cover that with the previous example. But there could be an addition of making the end block nullable.

Example of no end range, this would get the whole block range.

query {
    items(blockRange: [0, null]) {

As for other requirements:

• I think for now this can be limited to singular entities with an ID.
• There should be a limit to the number of results, same as how paging works, we don't want it to return a huge number of results, the default limit should be the same as the paging limit.
• Following on from the limit there also needs to be ASC/DESC for block height.

I think these are relatively straight forward in terms of how the API should be implemented but im happy to give examples if clarification is needed.

[stwiname]

@abhishek818 I've made a minor change to the issue. If there is an entity that gets deleted it should return null at the block height that it is removed. See the example in the issue for more details

[abhishek818]

@stwiname hey, some doubts..

example2: {
    // Keyed by block height
    5: {
      id: 'foo',
      field1: 1,
      field2: 'bar',
    },
    10: { 
    .....

Related to "Keyed by block height", do you mean there is always a 'created_at_block_height' or similar column in tables containing '_block_range' ?

90: null, // indicates the entity was deleted

Does this refers to a entity that is about to be deleted in the same graphql query containing blockRange param? If yes, can you give a example query..

There should be a limit to the number of results, same as how paging works, we don't want it to return a huge number of results, the default limit should be the same as the paging limit.

does this points to use of "limit " keyword of sql OR use of something like argv('query-limit') ?

[abhishek818]

damn, auckland timezone is way too ahead..

[abhishek818]

Alrighty, have got some idea after reading https://academy.subquery.network/indexer/run_publish/historical.html , will start implementing soon and then will ask any queries if needed.