[Feature] Allow getting and setting of indexed arguments / topic filters within handlers
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- typescript
- Domain
- blockchain
Research direction
Start by tracing the graph-ts handler and generated datasource APIs referenced in the issue, then determine how indexed topic filters are represented at handler runtime. Done means handlers can get a datasource's event handlers, read topic values, and update and save those values, with behavior covered by the relevant tests.
Written by the indexing model from the issue text.
Description
Description
The new indexed arguments filter is a big step forward in reducing indexing times when sifting through a large amount of events. This feature could be even more powerful as a dynamic datasource, similar to how templates operate. Ideally we could set the topic filter for a specific datasource at handler runtime. Alternatively, if we could specify templates with arguments, we could also create a new datasource and specify the topic.
Without understanding how the implementation actually works, being able to update an existing datasource seems like a more elegant solution (and a better solution for my use case). Three things would need to be exposed by graph-ts: Get Datasource, Read Topic Values, Set Topic Values. The API could look something like this:
// Since datasource names should be unique, these can be auto generated
import { DatasourceName } from '../generated'
import { Event } from '../generated/Contract/Contract'
export function handleEvent(event: Contract) {
const eventHandlers = DatasourceName.getEventHandlers();
const transferHandler = eventHandlers.filter(event => event.abi === 'Transfer(indexed address,indexed
address,uint256)');
const topics = transferHandler.topics;
transferHandler.topics = topics.concat([event.address.toHexString()]);
transferHandler.save();
}
Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.
No response
Some information to help us out
- Tick this box if you plan on implementing this feature yourself.
- I have searched the issue tracker to make sure this issue is not a duplicate.
- Dominant language
- Rust
- Stars
- 3.2k
- Forks
- 1.1k
- Avg merge
- 4d 1h
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from graphprotocol/graph-node
-
current: include emits an all-null bucket for dimensionless aggregations, nulling the whole response Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
graphprotocol/graph-node#6719 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
graphprotocol/graph-node#6673 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
graphprotocol/graph-node#6650 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
graphprotocol/graph-node#6722 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
graphprotocol/graph-node#6721 ·
All issues in graphprotocol/graph-node
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100