Rename chain_ids > chain_info_chain_ids hotfix

[hildobby]

Brief comments on the purpose of your changes:

For Dune Engine V2

I've checked that:

General checks:

• I tested the query on dune.com after compiling the model with dbt compile (compiled queries are written to the target directory)
• I used "refs" to reference other models in this repo and "sources" to reference raw or decoded tables
• if adding a new model, I added a test
• the filename is unique and ends with .sql
• each sql file is a select statement and has only one view, table or function defined
• column names are lowercase_snake_cased
• if adding a new model, I edited the dbt project YAML file with new directory path for both models and seeds (if applicable)
• if wanting to expose a model in the UI (Dune data explorer), I added a post-hook in the JINJA config to add metadata (blockchains, sector/project, name and contributor Dune usernames)

Pricing checks:

• coin_id represents the ID of the coin on coinpaprika.com
• all the coins are active on coinpaprika.com (please remove inactive ones)

Join logic:

• if joining to base table (i.e. ethereum transactions or traces), I looked to make it an inner join if possible

Incremental logic:

• I used is_incremental & not is_incremental jinja block filters on both base tables and decoded tables
  • where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to base table (i.e. ethereum transactions or traces), I applied join condition where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to prices view, I applied join condition where minute >= date_trunc("day", now() - interval '1 week')

[jeff-dude]

thank you ser, fixing dbt compile warnings

[jeff-dude]

hmm, looks the the anti join isn't dunesql compatible. since these are views, they'd need to be run on dunesql syntax too. i wonder if these were built prior to our gh action test for dunesql compatability. we could also check if they use the expose_spells_hide_trino macro in config since they are known to fail there, then we could look into merging regardless of passing that test

[Hosuke]

hmm, looks the the anti join isn't dunesql compatible. since these are views, they'd need to be run on dunesql syntax too. i wonder if these were built prior to our gh action test for dunesql compatability. we could also check if they use the expose_spells_hide_trino macro in config since they are known to fail there, then we could look into merging regardless of passing that test

We may rewrite anti join in equivalent left join logics.
eg.

select *
from a left join b
  on a.id = b.id
where b.id is NULL

[hildobby]

hmm, looks the the anti join isn't dunesql compatible. since these are views, they'd need to be run on dunesql syntax too. i wonder if these were built prior to our gh action test for dunesql compatability. we could also check if they use the expose_spells_hide_trino macro in config since they are known to fail there, then we could look into merging regardless of passing that test

We may rewrite anti join in equivalent left join logics. eg.

select *
from a left join b
  on a.id = b.id
where b.id is NULL

Issued another commit where I did that, lmk if fix is insufficient

[Hosuke]

Hi @hildobby, for the test failure, I cannot identify the exact cause at the moment.
But I am thinking it is not caused by the anti join.

It may be caused by the = operation in WHERE OR CASE OR ON CLAUSE.
eg.

One brute-force way to solve this problem, is to change the roll-up spell into incremental view.

Another appropriate solution, is to locate the column comparison and cast type on either side.
https://github.com/duneanalytics/spellbook/actions/runs/5120014833/jobs/9205990766?pr=3432#step:14:18

[MSilb7]

Tested the compiled bridge_flows and ran on dune.com in Spark and it worked with no datatype errors

[jeff-dude]

Tested the compiled bridge_flows and ran on dune.com in Spark and it worked with no datatype errors

is this still the case? i think we've seen this on other PRs too, where dunesql test is failing and i was a bit confused

[MSilb7]

Tested the compiled bridge_flows and ran on dune.com in Spark and it worked with no datatype errors

is this still the case? i think we've seen this on other PRs too, where dunesql test is failing and i was a bit confused

we should likely just cast the values anyway, I'll add a comment.

[Hosuke]

Wow it fixes.

[jeff-dude]

thanks all! i'll look to get this pushed through asap