-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(cross-chain-indexing): enable multiple concurrent plugins #24
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Super updates 👍 Reviewed and shared feedback 🙌
Apply PR suggestion regarding the in-code documentation Co-authored-by: lightwalker.eth <[email protected]>
Create an idepotenet function that takes a domain token ID and makes sure there is a database entity created for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Thanks for updates 👍 Reviewed and shared a few more points of feedback.
… -m "Had to replace `.onConflictDoNothing()` with `.onConflictDoUpdate({})` as the former would not return a DB entity if there was a conflict. The later would apply the delta on conflict, but since delta is an empty object, there will be no update at all. And yet, the existing DB entity will be always returned."
Declare all plugins active with the default `ACTIVE_PLUGINS` env var.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Hey nice updates, thanks. Just very minor nitpicks 👍
Co-authored-by: lightwalker.eth <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Thanks for updates. I made one last end-to-end review of the PR (rather than just reviewing the incremental changes since a prior review).
Let's do a great job on all the details. Thanks!
export default function () { | ||
// support NameRegisteredWithRecord for BaseRegistrar as it used by Base's RegistrarControllers | ||
ponder.on(pluginNamespace("BaseRegistrar:NameRegisteredWithRecord"), async ({ context, event }) => | ||
handleNameRegistered({ context, event }), | ||
); | ||
|
||
ponder.on(pluginNamespace("BaseRegistrar:NameRegistered"), async ({ context, event }) => { | ||
await upsertAccount(context, event.args.owner); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Thanks for the background info.
I'm still not clear here however.
The reason why is because I see the call to handleNameRegistered
at the end of this function. My understanding is that handleNameRegistered
will perform this upsertAccount
to match the subgraph equivalency you linked in your reply above.
So my question is still open: Why are we calling upsertAccount
again here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Very close. Getting there 😄 A few more feedbacks.
export default function () { | ||
// support NameRegisteredWithRecord for BaseRegistrar as it used by Base's RegistrarControllers | ||
ponder.on(pluginNamespace("BaseRegistrar:NameRegisteredWithRecord"), async ({ context, event }) => | ||
handleNameRegistered({ context, event }), | ||
); | ||
|
||
ponder.on(pluginNamespace("BaseRegistrar:NameRegistered"), async ({ context, event }) => { | ||
await upsertAccount(context, event.args.owner); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o This is still an open question for me. Can you please clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, merging
export default function () { | ||
// support NameRegisteredWithRecord for BaseRegistrar as it used by Base's RegistrarControllers | ||
ponder.on(pluginNamespace("BaseRegistrar:NameRegisteredWithRecord"), async ({ context, event }) => | ||
handleNameRegistered({ context, event }), | ||
); | ||
|
||
ponder.on(pluginNamespace("BaseRegistrar:NameRegistered"), async ({ context, event }) => { | ||
await upsertAccount(context, event.args.owner); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct.
side note: ponder doesn't enforce foreign key constraints in the postgres schema, so technically either order works but we should prefer the order you've suggested here, since domain records should depend on account record existing.
For example. with this change, it's possible to get a list of all names a given address owns across multiple chains (i.e.
base.eth
subnames on Base, andlinea.eth
subnames on Linea.Example query
Preview
Domain names under
eth
,base.eth
, andlinea.eth
:This PR overrides: