The Graph like entity CREATE, UPDATE & DELETE notifications

[bedeho]

I would like to ask what plans exist, or could exist, for accommodating the following in Subsquid, with some plausible timeline:

The Graph like entity CREATE, UPDATE & DELETE notifications

For each entity type, that there was a subscription that allowed the client to detect the three events CREATE, UPDATE and DELETE, with suitable parameter values included. This is already in The Graph, and would be very useful. It would also be very useful if these subscriptions allowed for some input parameters that defined some filtering conditions, so the client could narrow down the events of interest.

[dzhelezov]

Hey! Thanks for opening the issue. This has been in our backlog for a while. I cannot give a precise timeline for it, likely in Q2.

[eldargab]

Hey, @bedeho !

We started work on GraphQL subscriptions and decided to go for pull-based implementation.
This is for simplicity and also to support variety of databases which don't have common notification mechanism. In particular, we are interested in cockroach.

However, this doesn't deliver exactly what you requested. For example, subscription for entity updates without efficient narrow filter will be problematic.

Will such feature be still useful for you?

[bedeho]

Hi, appreciate the alert!

So I am not sure I really understand what you mean by pull-based subscription? Do you have some specification or rough design described somewhere?

[eldargab]

Basically it repeatedly executes the same query and sends notification to the client when its result changes.

[bedeho]

The node does this itself you mean?

What happens if an entity is mutated more than once between two pollings? Only the last update is announced? This would not be ideal, and can lead to very bad downstream effects if the client has mistaken semantics for the subscription, but it can also have some value compared to having nothing like today.

[eldargab]

What happens if an entity is mutated more than once between two pollings? Only the last update is announced?

Yes, exactly.

this would not be ideal, and can lead to very bad downstream effects if the client has mistaken semantics for the subscription

Treating arbitrary database updates as a sequence of actions sounds strange to me. If you have such cases I'm curious about that and would like to know more.

When we thought about subscriptions we just meant common case of updating UI to the current state, where any view is a pure function of state...

[bedeho]

When we thought about subscriptions we just meant common case of updating UI to the current state, where any view is a pure function of state...

No you may be right that this may be totally fine for most practical uses, I can't quickly give you a counterexample.