📰 2024-06-07: Weekly Prophet! #6114
andrewhong5297
announced in
Prophet (Weekly Updates)
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is your weekly summary of 63 PRs merged from 19 wizards. Great job everyone! 🎉
We had 222 added models 🟢 and 840 modified models 🟠 for 40 Sectors.
SECTOR: dex
toggle to see all model updates
MODEL: dex_solana_trades.sql
🟠 Modified by:
🔧 PR: #6072, add pumpdotfun to dex trades
🧙 Author: @andrewhong5297 on 2024-06-05
📝 Summary: A reference to a new model
pumpdotfun_solana_tradeswas added in the SQL code.MODEL: dex_raw_pools.sql
🟠 Modified by:
🔧 PR: #6082, Materialize dex raw pools
🧙 Author: @aalan3 on 2024-06-05
📝 Summary: Added a conditional block that includes an incremental predicate based on 'creation_block_time' if the model is running incrementally.
MODEL: dex_info.sql
🟠 Modified by:
🔧 PR: #5983, Add Nuri Scroll to dex.trades
🧙 Author: @Jam516 on 2024-06-03
📝 Summary: A new row for the project 'nuri' with corresponding values was added to the temporary table.
SECTOR: labels
toggle to see all model updates
MODEL: labels_op_retropgf.sql
🟠 Modified by:
🔧 PR: #6055, Move address_optimism, optimism_attestationstation and op
🧙 Author: @aalan3 on 2024-06-05
📝 Summary: Two SQL queries were updated to change the source of data from a dbt ref function to a source function. The model names and label types remained the same in both queries.
MODEL: labels_project_wallets.sql
🟠 Modified by:
🔧 PR: #6055, Move address_optimism, optimism_attestationstation and op
🧙 Author: @aalan3 on 2024-06-05
📝 Summary: The source reference in the model was changed from
addresses_optimism_grants_fundingtoaddresses_optimism.grants_funding. The comment line with UNION ALL was removed. The SELECT statement includes 'project_wallets' as model_name and 'identifier' as label_type, grouped by columns 1, 2, and 3.MODEL: labels_l2_fee_vaults.sql
🟠 Modified by:
🔧 PR: #6055, Move address_optimism, optimism_attestationstation and op
🧙 Author: @aalan3 on 2024-06-05
📝 Summary: Changed the source of data for the model from a dbt ref to a dbt source.
MODEL: labels_balancer_v2_pools_base.sql
🟠 Modified by:
🔧 PR: #6028, add ECLPs on base to balancer pool labels
🧙 Author: @viniabussafi on 2024-06-03
📝 Summary: A new pool type 'ECLP' was added to the CASE statement in the settings CTE. This change allows for lowercasing of pool symbols when the pool type is 'ECLP'.
MODEL: labels_beethoven_x_pools_fantom.sql
🟠 Modified by:
🔧 PR: #5964, Beethovenx/weightedv2 and composable stable
🧙 Author: @franzns on 2024-06-03
📝 Summary: Added pool_name to the pools CTE for each type of pool (weighted, stable, LBP) by joining with different factory tables. Added pool_name to the settings CTE and SELECT statement. Grouped by and included pool_name in the final SELECT query along with other columns like token_symbol, normalized_weight, etc., from settings table.
MODEL: labels_system_addresses.sql
🟠 Modified by:
🔧 PR: #6041, Daily spellbook contract mappings
🧙 Author: @aalan3 on 2024-05-31
📝 Summary: Added a CTE to select specific columns from a table and perform a UNION ALL operation with additional data. The query now references the source 'contracts' and 'system_predeploys', performs a LEFT JOIN, and filters out rows where an address match is not found in the existing curated_addresses table.
SECTOR: tokens
toggle to see all model updates
MODEL: tokens_solana_fees_history.sql
🟢 Added by:
🔧 PR: #6113, Token 2022 fungible (add metadata model first
🧙 Author: @andrewhong5297 on 2024-06-07
📝 Summary: This model extracts fee basis points, maximum fees, and timestamps for token transfers in the spl_token_2022_solana dataset. It enables data analysts to analyze transfer fees associated with specific tokens by providing insights into the fee structures and timing of transactions.
MODEL: tokens_solana_fungible.sql
🟠 Modified by:
🔧 PR: #6050, Token 2022 fungible (add metadata model first
🧙 Author: @andrewhong5297 on 2024-06-07
📝 Summary: The token symbols that were added are: 'wrapped SOL', 'SOL'
The token symbols that were removed are: None
🔧 PR: #6050, Revert 'add token2022 into token transfers and fungible spells (#6050)'
🧙 Author: @jeff-dude on 2024-06-06
📝 Summary: The token symbols that were added or removed are:
SOL, wrapped SOL
🔧 PR: #6050, add token2022 into token transfers and fungible spells
🧙 Author: @andrewhong5297 on 2024-06-06
📝 Summary: The token symbols that were added are: 'wrapped SOL', 'SOL'
The token symbols that were removed are: None
MODEL: tokens_solana_transfers.sql
🟠 Modified by:
🔧 PR: #6050, Revert 'add token2022 into token transfers and fungible spells (#6050)'
🧙 Author: @jeff-dude on 2024-06-06
📝 Summary: [changes too large] The model tokens_solana_transfers.sql was modified.
🔧 PR: #6050, add token2022 into token transfers and fungible spells
🧙 Author: @andrewhong5297 on 2024-06-06
📝 Summary: [changes too large] The model tokens_solana_transfers.sql was modified.
SECTOR: prices
toggle to see all model updates
MODEL: prices_base_tokens.sql
🟠 Modified by:
🔧 PR: #5918, add new tokens to price list [base]
🧙 Author: @RantumBits on 2024-06-05
📝 Summary: POLA, JOGECO, BOSHI, DOOMER, ROCK, BLOOM, CAW1 , KEREN , MOG , CARLO , SKI KURBI BORD
MODEL: prices_ethereum_tokens.sql
🟠 Modified by:
🔧 PR: #5919, add new tokens to price list [ethereum]
🧙 Author: @RantumBits on 2024-06-05
📝 Summary: BONK, ZYN, NUT, NMT, SIMPSON, PONGO, TRUF, PEPECOIN,
GPU,D OGE20 ,CHAD
MODEL: prices_arbitrum_tokens.sql
🟠 Modified by:
🔧 PR: #6057, Add missing tokens on tokens.erc20 and prices.usd
🧙 Author: @viniabussafi on 2024-06-03
📝 Summary: The token symbols that were added or removed are: GYD, A51
🔧 PR: #6057, Added new tokens to Arbitrum tokens model
🧙 Author: @yy-analytics on 2024-06-03
📝 Summary: The tokens that were added are: USDe
SECTOR: staking
toggle to see all model updates
MODEL: staking_ethereum_entities_depositor_addresses.sql
🟠 Modified by:
🔧 PR: #6047, More stakers
🧙 Author: @hildobby on 2024-06-06
📝 Summary: [changes too large] The model staking_ethereum_entities_depositor_addresses.sql was modified.
MODEL: staking_ethereum_info.sql
🟠 Modified by:
🔧 PR: #6047, More stakers
🧙 Author: @hildobby on 2024-06-06
📝 Summary: Added new entities and their corresponding x_usernames, including 'Puffer Finance' with 'puffer_finance', 'Eigenpie' with 'Eigenpiexyz_io'. Also added two unknown clusters with their respective URLs.
MODEL: staking_ethereum_entities_batch_contracts_tx_from.sql
🟠 Modified by:
🔧 PR: #5996, Add stakers
🧙 Author: @hildobby on 2024-06-05
📝 Summary: Two entities were added to the 'tagged_entities' CTE: one for 'Bitpanda' under the category 'CEX', and another for 'Golem Foundation' under the category 'Staking Pool'.
MODEL: staking_ethereum_deposits.sql
🟠 Modified by:
🔧 PR: #6063, Incremental predicate various models
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added logic to use an incremental predicate for filtering based on block time in the deposit_events CTE and transactions table. The date condition was updated from a fixed date to using the incremental predicate function.
🔧 PR: #6063, Add incremental predicates on zeroex
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added logic to filter deposit events based on the block time within the last 7 days. Removed a section related to traces and adjusted the left join condition with additional checks for pubkey, withdrawal credentials, and sub-entity in staking_ethereum_entities table.
SECTOR: cow_protocol
toggle to see all model updates
MODEL: cow_protocol_ethereum_batches.sql
🟠 Modified by:
🔧 PR: #6060, Add incremental predicates on cow
🧙 Author: @aalan3 on 2024-06-06
📝 Summary: Added logic to filter incremental data based on a specific time interval.
🔧 PR: #6060, Use incremental predicates in cow_protocol
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added logic to use an incremental predicate function for filtering data based on block time within a specific timeframe.
MODEL: cow_protocol_gnosis_batches.sql
🟠 Modified by:
🔧 PR: #6060, Add incremental predicates on cow
🧙 Author: @aalan3 on 2024-06-06
📝 Summary: Added a conditional statement to filter data incrementally based on the 'minute' time unit.
🔧 PR: #6060, Use incremental predicates in cow_protocol
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: In the
batch_countsCTE, logic was added to use an incremental predicate for filtering based on event block time. In the same CTE and in thecombined_batch_infoCTE, similar logic was added using incremental predicates for filtering based on event block time and transaction block time respectively. Additionally, in thebatch_valuesCTE, a similar change was made to filter based on block time using an incremental predicate when it is an incremental run.MODEL: cow_protocol_arbitrum_trades.sql
🟢 Added by:
🔧 PR: #6038, Adding Arbitrum Chain to CoW Protocol
🧙 Author: @olgafetisova on 2024-06-03
📝 Summary: This model enables data analysts to analyze trades with buy and sell token prices, deduct fees from sell amounts, get token symbols and decimals for units bought and sold, sort orders by event index within each transaction hash, map order UIDs to application IDs for further analysis of trade details including values in USD. It also calculates surplus in both relative percentage and absolute USD value based on executed price compared to the limit price.
🟠 Modified by:
🔧 PR: #6038, Use incremental predicates in cow_protocol
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: In the
trades_with_pricessubquery, logic was added to use an incremental predicate for filtering data based on a specific time range. The same incremental predicate logic was also added in thesorted_orderssubquery for filtering data based on event block time within a certain timeframe.MODEL: cow_protocol_ethereum_eth_flow_orders.sql
🟠 Modified by:
🔧 PR: #6060, Use incremental predicates in cow_protocol
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: The logic added in this change is to replace the hard-coded date filter with an incremental predicate function for 'evt_block_time' and 'call_block_time'. This change allows for dynamic filtering based on the incremental loading strategy.
MODEL: cow_protocol_ethereum_trades.sql
🟠 Modified by:
🔧 PR: #6060, Use incremental predicates in cow_protocol
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: In the
trades_with_pricesmodel, the condition for filtering rows based on a specific time range was changed to use an incremental predicate function. Similarly, in thesorted_ordersandeth_flow_sendersmodels, the filtering conditions were also updated to utilize an incremental predicate function instead of specifying a fixed time range.MODEL: cow_protocol_gnosis_trades.sql
🟠 Modified by:
🔧 PR: #6060, Use incremental predicates in cow_protocol
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added logic to use an incremental predicate for filtering data based on a specific time range. The incremental predicate is applied to the 'ps.minute', 'pb.minute', and 'evt_block_time' columns in different parts of the model, ensuring that only relevant data within the specified time frame (last 7 days) is included in the query results.
MODEL: cow_protocol_trades.sql
🟠 Modified by:
🔧 PR: #6038, Adding Arbitrum Chain to CoW Protocol
🧙 Author: @olgafetisova on 2024-06-03
📝 Summary: A new section was added to the SQL model that selects data from a different source related to 'arbitrum' blockchain trades. The selected columns include information such as blockchain, project, version, token symbols and amounts bought/sold, USD value, addresses of tokens and traders involved in the trade.
MODEL: cow_protocol_tx_hash_labels_offramp_ethereum.sql
🟠 Modified by:
🔧 PR: #6034, Move nft tokens metadata to tokens subproject
🧙 Author: @aalan3 on 2024-05-31
📝 Summary: Added source() function to replace ref() function for tokens_ethereum_erc20_stablecoins.
MODEL: cow_protocol_tx_hash_labels_onramp_ethereum.sql
🟠 Modified by:
🔧 PR: #6034, Move nft tokens metadata to tokens subproject
🧙 Author: @aalan3 on 2024-05-31
📝 Summary: Added source function to replace ref function for tokens_ethereum_erc20_stablecoins.
MODEL: cow_protocol_tx_hash_labels_stable_to_stable_ethereum.sql
🟠 Modified by:
🔧 PR: #6034, Move nft tokens metadata to tokens subproject
🧙 Author: @aalan3 on 2024-05-31
📝 Summary: Added source() function to replace ref() function for tokens_ethereum_erc20_stablecoins in two select statements.
SECTOR: _sector
toggle to see all model updates
MODEL: cex_flows.sql
🟢 Added by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: This model combines data from various centralized exchanges (CEX) flows into a single dataset. It enables data analysts to analyze and compare blockchain transactions across different CEX platforms based on attributes such as blockchain, block details, token information, flow type, transaction amounts in various currencies, addresses involved in the transactions, and unique identifiers. The model supports incremental loading of data based on block time criteria for efficient updates.
🟠 Modified by:
🔧 PR: #6031, Add chains to
cex_{chain}.flows🧙 Author: @hildobby on 2024-06-06
📝 Summary: Two references were added: 'cex_fantom_flows' and 'cex_linea_flows'.
🔧 PR: #6031, fix cex flows column
🧙 Author: @jeff-dude on 2024-06-05
📝 Summary: Added quotes around a column name 'from' and removed a column named 'from'.
MODEL: cex_fantom_flows.sql
🟢 Added by:
🔧 PR: #5990, Add chains to
cex_{chain}.flows🧙 Author: @hildobby on 2024-06-06
📝 Summary: This SQL model creates a CEX flows table that enables data analysts to track and analyze the flow of tokens on the Fantom blockchain. It references tables for token transfers and addresses specific to the Fantom blockchain, allowing for detailed analysis of transactions within centralized exchanges on this network.
MODEL: cex_linea_flows.sql
🟢 Added by:
🔧 PR: #5990, Add chains to
cex_{chain}.flows🧙 Author: @hildobby on 2024-06-06
📝 Summary: This SQL model creates a CEX flows table that enables data analysts to analyze and track the flow of tokens on the specified blockchain. It references tables for transfers and addresses specific to the chosen blockchain, linea.
MODEL: cex_zkevm_flows.sql
🟢 Added by:
🔧 PR: #5990, Add chains to
cex_{chain}.flows🧙 Author: @hildobby on 2024-06-06
📝 Summary: This model creates a CEX flows table that enables data analysts to analyze and track the flow of tokens on a specific blockchain (in this case, zkevm). The table includes information on transfers and addresses related to centralized exchange transactions for the specified blockchain.
MODEL: cex_arbitrum_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate was added to the model, specifically targeting 'DBT_INTERNAL_DEST.block_time'.
MODEL: cex_avalanche_c_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate for 'DBT_INTERNAL_DEST.block_time' was added to the model.
MODEL: cex_base_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate was added to the model, specifying 'DBT_INTERNAL_DEST.block_time' as the condition for incrementally updating data.
MODEL: cex_bnb_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate was added to the model, specifying a column to use for incremental updates.
MODEL: cex_celo_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate for 'DBT_INTERNAL_DEST.block_time' was added to the model.
MODEL: cex_ethereum_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate was added to the model, specifying 'DBT_INTERNAL_DEST.block_time' as the condition for incrementally updating data.
MODEL: cex_gnosis_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate for 'DBT_INTERNAL_DEST.block_time' was added to the model.
MODEL: cex_optimism_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate on 'DBT_INTERNAL_DEST.block_time' was added to the model.
MODEL: cex_polygon_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate for 'DBT_INTERNAL_DEST.block_time' was added to the model.
MODEL: cex_scroll_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate for 'DBT_INTERNAL_DEST.block_time' was added to the model.
MODEL: cex_zksync_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate on 'DBT_INTERNAL_DEST.block_time' was added to the model.
MODEL: cex_zora_flows.sql
🟠 Modified by:
🔧 PR: #6031, Create croscchain
cex.flows🧙 Author: @hildobby on 2024-06-05
📝 Summary: An incremental predicate for the column 'block_time' was added to the model. This predicate is used in conjunction with an incremental merge strategy and a unique key constraint on columns 'flow_type' and 'unique_key'. The materialization type is set to incremental with a delta file format.
MODEL: banana_gun_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'block_time' to support incremental processing based on changes in that column.
MODEL: bonkbot_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'block_time' to the model for incremental materialization strategy using merge, with a unique key defined across multiple columns. The file format is set to delta.
MODEL: consortium_key_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: The incremental strategy was changed to use single quotes instead of double quotes. Additionally, an incremental predicate using 'DBT_INTERNAL_DEST.block_time' was added for the model.
MODEL: looter_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on 'DBT_INTERNAL_DEST.block_time' to the dbt SQL model with incremental materialization strategy set to 'merge'.
MODEL: maestro_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on 'DBT_INTERNAL_DEST.block_time' to the model.
MODEL: magnum_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'block_time' to support incremental processing based on changes in that column.
MODEL: pepe_boost_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'block_time' to support incremental processing based on changes in that column.
MODEL: readyswap_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'block_time' to support incremental materialization strategy using merge logic.
MODEL: shuriken_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'block_time' to support incremental materialization strategy for merging data.
MODEL: sol_gun_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on 'DBT_INTERNAL_DEST.block_time' to the dbt SQL model for incremental materialization using a merge strategy with a unique key defined on multiple columns. The materialization is set to 'incremental' and file format as 'delta'.
MODEL: sol_trading_bot_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'DBT_INTERNAL_DEST.block_time' to support incremental materialization strategy using merge logic.
MODEL: soul_sniper_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on 'DBT_INTERNAL_DEST.block_time' for the incremental model. The logic was modified to include this new incremental predicate in the WHERE clause when determining which records to select based on whether it is an incremental run or a full refresh.
MODEL: trojan_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on the column 'block_time' to support incremental processing based on changes in that column.
MODEL: wifbot_solana_bot_trades.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on 'DBT_INTERNAL_DEST.block_time' for the incremental model. The logic was modified to use this new incremental predicate instead of 'block_time'.
MODEL: magiceden_solana_events.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate on 'DBT_INTERNAL_DEST.block_time' and replaced the date filter conditions with incremental predicates for 'block_time' and 'p.minute'.
MODEL: opensea_solana_events.sql
🟠 Modified by:
🔧 PR: #6061, Incremental predicates solana
🧙 Author: @aalan3 on 2024-06-04
📝 Summary: Added an incremental predicate for 'DBT_INTERNAL_DEST.block_time'. Replaced a condition with an incremental predicate for 'p.minute' and another one for 'block_time'.
MODEL: nft_old_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, chore: review solana trades setup
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Removed 'magiceden_solana_events' and 'opensea_solana_events' from the list of nft_models, while added 'nftearth_optimism_events'.
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Removed references to various OpenSea events on different blockchains (Arbitrum, Ethereum, Optimism, Polygon) and Avalanche from the dbt SQL model.
MODEL: nft_solana_base_trades.sql
🟢 Added by:
🔧 PR: #5979, chore: review solana trades setup
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: This SQL model creates a transformative view that aims to populate the
nft.tradestable with Solana trades data. The view includes various columns such as blockchain details, trade specifics, buyer/seller information (encoded), transaction details, fees, and more. It focuses on accurately capturing transaction count and overall volume for analysis purposes. Some values are cast to varbinary despite potential encoding issues but maintain equality and uniqueness constraints. This model enhances data analysts' ability to analyze Solana trade activities within the specified parameters provided in the query results.MODEL: nft_solana_old_trades.sql
🟢 Added by:
🔧 PR: #5979, chore: review solana trades setup
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: This model combines data from multiple NFT marketplace events tables into a unified format. It transforms columns to align with a new schema, handling null values where necessary. The resulting table includes information such as trade details, buyer and seller identifiers, fees, and transaction specifics. This consolidation simplifies analysis for data analysts working across different NFT marketplaces by providing a standardized dataset for querying and reporting purposes.
MODEL: nft_solana_trades.sql
🟠 Modified by:
🔧 PR: #5979, chore: review solana trades setup
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: A new reference to 'nft_solana_old_trades' was added in the SQL model. Additionally, a loop that iterates over references and includes a UNION ALL statement between them was updated.
MODEL: nft_arbitrum_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Two references were added to the SQL model: 'opensea_v3_arbitrum_base_trades' and 'opensea_v4_arbitrum_base_trades'.
MODEL: opensea_v3_arbitrum_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Changed unique key columns from ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id', 'sub_type', 'sub_idx'] to ['block_number', 'tx_hash','sub_tx_trade_id']. Materialized as incremental with delta file format and merge incremental strategy.
MODEL: opensea_v4_arbitrum_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The unique key in the dbt SQL model was changed from a list of columns to a new list containing 'block_number', 'tx_hash', and 'sub_tx_trade_id'. The materialization is set to incremental, file format to delta, and incremental strategy to merge.
MODEL: nft_avalanche_c_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Two references were added ('element_avalanche_c_base_trades', 'opensea_v3_avalanche_c_base_trades', 'opensea_v4_avalanche_c_base_trades') and one reference was removed ('element_avalanche_c_base_trades').
MODEL: opensea_v3_avalanche_c_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Changed the unique key columns in an incremental model from ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id', 'sub_type', 'sub_idx'] to ['block_number','tx_hash','sub_tx_trade_id'].
MODEL: opensea_v4_avalanche_c_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Changed the unique key columns in an incremental model from ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id', 'sub_type', 'sub_idx'] to ['block_number','tx_hash','sub_tx_trade_id'].
MODEL: nft_base_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: A reference to 'opensea_v4_base_base_trades' was added in the SQL model.
MODEL: opensea_v4_base_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The unique key in the model was changed to include 'block_number', 'tx_hash', and 'sub_tx_trade_id' instead of ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id','sub_type','sub_idx']. The materialization is set to incremental, file format as delta, and incremental strategy as merge.
MODEL: nft_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Two references were added to the SQL model: 'opensea_v3_ethereum_base_trades' and 'opensea_v4_ethereum_base_trades'.
MODEL: opensea_v3_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Changed the unique key columns in the model from ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id', 'sub_type', 'sub_idx'] to ['block_number','tx_hash','sub_tx_trade_id'].
MODEL: opensea_v4_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added a unique key constraint with three columns and removed a temporary fix to exclude duplicates based on specific columns.
MODEL: nft_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Two references were added to the model: 'opensea_v3_optimism_base_trades' and 'opensea_v4_optimism_base_trades'.
MODEL: opensea_v3_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The unique key in the dbt SQL model was changed from a list of columns to a new list containing 'block_number', 'tx_hash', and 'sub_tx_trade_id'. The materialization type is incremental, file format is delta, and incremental strategy is merge.
MODEL: opensea_v4_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The unique key in the dbt SQL model was changed to include 'block_number', 'tx_hash', and 'sub_tx_trade_id' instead of ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id','sub_type','sub_idx']. The materialization is set to incremental, file format as delta, and incremental strategy as merge.
MODEL: nft_polygon_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Two references were added to the SQL model: 'opensea_v3_polygon_base_trades' and 'opensea_v4_polygon_base_trades'.
MODEL: opensea_v3_polygon_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Changed the unique key columns in the model from ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id', 'sub_type', 'sub_idx'] to ['block_number','tx_hash','sub_tx_trade_id'].
MODEL: opensea_v4_polygon_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added a unique key constraint on columns 'block_number', 'tx_hash', and 'sub_tx_trade_id'. Removed logic to exclude duplicates based on multiple columns in the trades table.
MODEL: nft_zora_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Two new models, 'opensea_v4_zora_base_trades' and 'zonic_zora_base_trades', were added to the list of nft_models.
MODEL: opensea_v4_zora_base_trades.sql
🟠 Modified by:
🔧 PR: #6000, Seaport refactor to base trades schema
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The unique key in the dbt SQL model was changed to include 'block_number', 'tx_hash', and 'sub_tx_trade_id' instead of ['tx_hash', 'evt_index', 'nft_contract_address', 'token_id','sub_type','sub_idx']. The materialization is set to incremental with a file format of delta, using an incremental strategy of merge.
MODEL: nft_transfers.sql
🟠 Modified by:
🔧 PR: #6023, partition NFT spells by blockchain
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added 'blockchain' to the partition_by list.
MODEL: sudoswap_v2_arbitrum__pools.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added logic to select and join data from different sources based on specific conditions, including filtering by a date range.
MODEL: magiceden_base_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The logic added includes filtering and aggregating data from a table using specific conditions. A join operation is performed between two tables based on certain criteria, with additional transformations applied to calculate different fee amounts. Additionally, a function call is made to add transaction data once it becomes available in the base event tables.
MODEL: sudoswap_v2_base__pools.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added logic to select pool creations with specific attributes like pool address, NFT contract address, and bonding curve. The query now includes a union of two subqueries that extract these attributes from JSON parameters. Additionally, there is a condition for incremental loading based on the call block time within the last 7 days. Joined this data with transaction details to get creator addresses for each pool creation entry.
MODEL: collectionswap_ethereum__pools.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: [changes too large] The model collectionswap_ethereum__pools.sql was renamed.
MODEL: collectionswap_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: A reference to a dbt model named 'collectionswap_ethereum_pools' was updated to 'collectionswap_ethereum__pools' in the left join condition of the SQL query.
MODEL: sudoswap_v2_ethereum__pools.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added logic to select pool creations with specific attributes like pool address, NFT contract address, and creator address. The model now includes conditions for selecting data based on a time interval and joins the selected data with Ethereum transactions based on block time, transaction hash, and success status.
MODEL: quix_v1_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added logic to the SQL model includes changing references from 'transfers_optimism_eth' to 'tokens_optimism_base_transfers', updating column names, and adjusting conditions for block numbers and amounts. Removed logic involves a union with ERC20 royalties, along with related columns and conditions. Additionally, removed filtering based on ERC20 values being not null.
MODEL: quix_v2_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Removed logic related to eth and erc20 royalties calculations. Updated the
transfersCTE to use a different reference table for transfers data (tokens_optimism_base_transfers). Replaced references fromtx_block_numberwithblock_number, and changed value casting fromvaluetoamount_raw. Added conditions for filtering out specific addresses in the join clause. Adjusted condition for block number based on whether it is incremental or not, and added a condition based on block time if it is incremental.MODEL: quix_v3_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: Added logic to filter out specific events and calculate royalties based on block number, time, transaction hash, value amount, and recipient. Replaced a reference table with a new one for transfers data. Adjusted conditions for joining tables based on the updated column names and added additional filtering criteria related to minimum block numbers and incremental updates.
MODEL: quix_v4_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The logic added involves changing the column names and conditions for joining two tables. The block number, block time, value, and other columns are adjusted accordingly. Additionally, the condition for filtering rows based on amount_raw is updated to be greater than 0 instead of value_decimal being greater than 0. There are also modifications in checking the block number against a minimum threshold and adjusting it based on whether it's an incremental run or not.
MODEL: quix_v5_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: The changes involve renaming columns and adjusting conditions for joining tables. The column names
tx_block_numberandtx_block_timewere changed toblock_numberandblock_time, respectively. Additionally, the condition for filtering rows based on value was updated to use the new column name (amount_raw) instead of the previous one (value). The join condition now compares against a different table (tokens_optimism_base_transfers). Some conditions related to block numbers were also modified, along with adjustments in date comparisons within conditional blocks.MODEL: nft_base_trades.sql
🟠 Modified by:
🔧 PR: #6039, Clean up NFT incoming lineage
🧙 Author: @0xRobin on 2024-06-03
📝 Summary: A reference to a new table
nft_zora_base_tradeswas added to the model.MODEL: alm_trades.sql
🟢 Added by:
🔧 PR: #5764, feat: setup ALM trades + feed Arrakis data
🧙 Author: @0xrusowsky on 2024-06-03
📝 Summary: This model creates a union of data from the 'alm_ethereum_trades' table, allowing data analysts to analyze various fields related to blockchain trades such as project, version, dex information, token pairs and volumes. The model also includes logic to handle incremental updates based on block time and removes duplicate entries based on specific criteria. Analysts can use this consolidated dataset for further analysis and reporting purposes.
MODEL: alm_ethereum_trades.sql
🟢 Added by:
🔧 PR: #5764, feat: setup ALM trades + feed Arrakis data
🧙 Author: @0xrusowsky on 2024-06-03
📝 Summary: This model creates a union of data from the 'arrakis_finance_ethereum_tra
Beta Was this translation helpful? Give feedback.
All reactions