zereox - v2 macro replacements 2 #7168
Conversation
|
@jeff-dude i got this updated v2 macro to run successfully. there was an issue with a invalid taker value internally in some cases that i didn't catch for a while. i've implemented a few enhancements - lmk if you see room for anything further. |
There was a problem hiding this comment.
(assuming i didn't break anything, CI is running as i type)
this looks good to me. i added a few comments, more for my understanding as i looked closer at the macros. i also attempted to simplify the metadata reads in final details macro, to simply pull the data incrementally per chain and then later downstream the join from transactional data to metadata has our required timesetamp / address conditions.
one piece i looked closely at but wasn't sure how to improve performance (or if it can be) is around this logic in the settler_txs macro:
WHERE
(a.settler_address IS NOT NULL OR tr.to in (0x0000000000001fF3684f28c67538d4D072C22734,0x0000000000005E88410CcDFaDe4a5EfaE4b49562,0x000000000000175a8b9bC6d539B3708EEd92EA6c))
i've noticed dunesql engine can struggle on those OR statements including varbinary addresses. also just joining on address in general back to larger raw tables, but that is seemingly the only way to cut down the number of transactions tied to settler addresses
|
interesting, looks like we had performance enhancements with simplifying the metadata CTEs. it's possible it's noise due to CI env being less busy than last run, but still a good sign to consider before merging. i will likely merge this tomorrow |
Thank you for contributing to Spellbook 🪄
Please open the PR in draft and mark as ready when you want to request a review.
Description:
[...]
quick links for more information: