Add a _changeBlock attribute on all entities

[azf20]

Graph Node tracks the block range over which a given entity is active. This effectively captures the block when an entity was last changed. This could be surfaced in the graphQL API as an automatically generated field _changeBlock. This field would provide helpful metadata, as well as being useful for filtering or sorting (using the logic applied to other fields).

e.g.

tokens(orderBy: _changeBlock, orderDirection: desc, where: { _changeBlock_gt: 99999 } ) {
    id
    _changeBlock
}

This would also help with polling for new entities & other requested use-cases.

[Jannis]

Closely related: #295 (confirmations API). The confirmations API might be overkill but it's worth considering use cases before we add an API change that we then need to maintain forever.

[azf20]

Yes there are definitely overlaps, though I think the confirmations API requires quite a lot more functionality (field level details, details on the changes, finalization) which is beyond the scope of this issue.

You do raise a good point on an API change that we then need to maintain forever. I think there is a question whether we want to maintain the _meta pattern that exists at the top level of the subgraph, where _changeBlock is part of _meta (and which leaves more scope for potential extension in the future).

[dotansimha]

Do those fields are considered as data or metadata? (needed for app development, or only while manually querying/testing the subgraph API?)

Because I think we can consider creating a spec for thegraph-introspection that exposes those? Just like GraphQL has it's own introspection that starts with __, we can introduce an internal introspection that can be part of every type / schema, and have it's own lifecycle? (so we can decide if we break/maintain it or not, and make a statement that it's an internal API that is subject to changes?)

[azf20]

Interesting - if that is an established pattern that could work, and as you say it has the benefit of flexibility. To answer the first question, this would be useful for app development, for example when polling for new data, or finding recently changed entities - so that does make it a bit more difficult to break anything, once introduced

[azf20]

OK. Revisiting this, I am tempted to opt for the simpler approach described in this issue: #1838
This adds this functionality purely as a new filter in the top-level where, rather than as an extension to the entity itself. This means that it is not available to Select, or Orderby.

[azf20]

Closing for now as this was implemented as a filter, we can establish whether adding this information to the entity would be useful