Create nft_blast.wash_trades

[hildobby]

blocked by #6151

[hildobby]

added addresses_events_blast.first_funded_by as a source like the other chains, but it doesnt work. what is going on @jeff-dude ?

[0xRobin]

The PR that added the model was merged yesterday after the daily spellbook job started (12:00 UTC).
We'll be able to rerun this CI once the model is created today (should be around 13:30 UTC)

[jeff-dude]

The PR that added the model was merged yesterday after the daily spellbook job started (12:00 UTC). We'll be able to rerun this CI once the model is created today (should be around 13:30 UTC)

do you think we need to move those models into nft subproject, since they are used in wash trades?

is that the sole purpose for these spells (first_funded_by)?

[0xRobin]

do you think we need to move those models into nft subproject, since they are used in wash trades?

is that the sole purpose for these spells (first_funded_by)?

good Q, I'm not sure.
I've always envisioned them to be more broadly applicable than only wash trades. (clustering, sybil detection, ...)
But for now, in spellbook, they are only used for wash trades

[jeff-dude]

looks like similar questions were asked in the PR which moved address events to daily spellbook. we should revisit the discussion on cross-project coordination + timing of runs for dependencies. with things broken out and more capacity on each cluster, we may want to open the incremental predicate back to a few more days to catch the differences

[hildobby]

The PR that added the model was merged yesterday after the daily spellbook job started (12:00 UTC). We'll be able to rerun this CI once the model is created today (should be around 13:30 UTC)

do you think we need to move those models into nft subproject, since they are used in wash trades?

is that the sole purpose for these spells (first_funded_by)?

I use them across many different projects (that for now are mostly in dune queries) with nfts being just one of them. it's probably one of the spells i use most since i need to sleuth addresses for all kinds of things: eth staking, blobs, cex addresses, etfs (daily run on those means etf updates now have a bare minimum delay of 1 day).

it will be used a lot more in spellbook soon, here's a wip PR example where i absolutely need it: github.com//pull/5986

i really wish this still ran as often as it did, now for any super short term analysis, i've started moving my work locally instead of using dune

overall though, could we find a solution that doesn't necessitate creating a new sources doc for every spellbook section, this is a headache to work with

[hildobby]

wtf dbt tests are fast af in subprojects now, cool af gg guys 🫡

[0xRobin]

i really wish this still ran as often as it did, now for any super short term analysis, i've started moving my work locally instead of using dune

This is valuable feedback, the new push has been to move to 'daily by default' instead of 'hourly by default'. But this doesn't mean all models will be daily, there's room for models to be run hourly if they warrant it. Note, this is all new and we're still figuring out the correct process for this. I'll bring it up internally.

overall though, could we find a solution that doesn't necessitate creating a new sources doc for every spellbook section, this is a headache to work with

Can you expand on this? Not sure what you refer to.

[hildobby]

i really wish this still ran as often as it did, now for any super short term analysis, i've started moving my work locally instead of using dune

This is valuable feedback, the new push has been to move to 'daily by default' instead of 'hourly by default'. But this doesn't mean all models will be daily, there's room for models to be run hourly if they warrant it. Note, this is all new and we're still figuring out the correct process for this. I'll bring it up internally.

🙏 i know that overall the goal is to have the bulk of models running daily (which makes a lot of sense) but what is the process to make a case for "this one should run hourly"?

also, one thing to think about is that all users assume that when a query just ran it's now assumed to be realtime data (or really close), this change does mean that when using any spell from the daily subproject, this is no longer true. that's going to lead to a lot of confused users imo

overall though, could we find a solution that doesn't necessitate creating a new sources doc for every spellbook section, this is a headache to work with

Can you expand on this? Not sure what you refer to.

for every model i need in a subproject that was made in another, it needs to be added as a source, is there a way to automate this source import? that would make it easier to contribute to spellbook + having the same spells defined multiple times makes it really confusing to work with

maybe local scripts could help! i tried working on those a while back but then there was a migration making my work useless so i scrapped it. with regular migration like lately it makes it hard to create those externally without any idea on your internal spellbook short term roadmap

[0xRobin]

for every model i need in a subproject that was made in another, it needs to be added as a source, is there a way to automate this source import?

We should aim for this to be the exception, rather then something that's regularly needed. It's best if the whole lineage of models is part of the same subproject and we should try to minimize the cross-project dependencies.

[jeff-dude]

@hildobby we hear you on this. thanks for continuing to push it.

since we don't have a formalized process in place yet for promoting spells to hourly, we can take a shortcut in this instance. it's good to know you use those spells for a lot of other use cases. we also leverage a lot of your curated spells in things like labels, so it's logical to keep these important ones hourly.

let's follow up in another PR to get those moved. for now, due to urgency around this PR, i will look to get it merged.

[jeff-dude]

wtf dbt tests are fast af in subprojects now, cool af gg guys 🫡

also noticed this run was so fast due to no models being picked up in state:modified comparison, so nothing ran. it's odd to see that, so let's see how this latest CI run goes. if nothing runs, we will need to look into that. it is still faster though in general 🫡

[jeff-dude]

okay, cool, it ran this time 🙌
only ~4 minutes for it all