📰 2023-11-24: Weekly Prophet! #4872
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
Uh oh!
There was an error while loading. Please reload this page.
-
This is your weekly summary of 32 PRs merged from 16 wizards. Great job everyone! 🎉
We had 74 added models 🟢 and 95 modified models 🟠 for 24 Sectors.
SECTOR: dex
toggle to see all model updates
MODEL: dex_solana_trades.sql
🟠 Modified by:
🔧 PR: #4850, add goosefx to solana dex
🧙 Author: @andrewhong5297 on 2023-11-22
📝 Summary: A reference to the 'goosefx_ssl_v2_solana_trades' table was added in this SQL model.
MODEL: dex_trades.sql
🟠 Modified by:
🔧 PR: #4769, Added woofi optimism dex
🧙 Author: @ARDev097 on 2023-11-22
📝 Summary: The reference models that were added or removed in the diff are: woofi_optimism_trades.
MODEL: dex_base_addresses.sql
🟠 Modified by:
🔧 PR: #4843, dex addresses
🧙 Author: @RantumBits on 2023-11-21
📝 Summary: The main logic added in this SQL model is the inclusion of a new column called 'blockchain' in the SELECT statement. The VALUES clause was also modified to include the 'base' value for each row, and the column name was changed from 'address' to 'blockchain'.
MODEL: dex_addresses.sql
🟢 Added by:
🔧 PR: #4843, dex addresses
🧙 Author: @RantumBits on 2023-11-21
📝 Summary: This SQL model creates a union of multiple address tables (dex_arbitrum_addresses, dex_base_addresses, dex_bnb_addresses, dex_ethereum_addresses, dex_optimism_addresses, and dex_polygon_addresses). It enables data analysts to query all the address data from these tables in one consolidated result set.
MODEL: dex_ethereum_addresses.sql
🟠 Modified by:
🔧 PR: #4824, dex addresses
🧙 Author: @RantumBits on 2023-11-21
📝 Summary: [changes too large] The model dex_ethereum_addresses.sql was modified.
🔧 PR: #4824, dex addresses: standardize to other blockchains
🧙 Author: @jeff-dude on 2023-11-17
📝 Summary: In the given SQL model, a SELECT statement is used to retrieve data from three columns: address, dex_name, and distinct_name. The data is selected from a VALUES clause which contains an unspecified number of rows and values. No further information or details are provided in the diff.
MODEL: dex_optimism_addresses.sql
🟢 Added by:
🔧 PR: #4784, Add dex/agg routers on Optimism [FOR REVIEW]
🧙 Author: @RantumBits on 2023-11-17
📝 Summary: This SQL model creates a table that includes columns for blockchain, address, dex_name, and distinct_name. It populates the table with values for these columns from a VALUES statement. This model enables data analysts to query and analyze information related to different blockchains, addresses, decentralized exchanges (dex), and distinct names within those exchanges.
MODEL: dex_arbitrum_addresses.sql
🟢 Added by:
🔧 PR: #4790, add dex/agg routers - Arbitrum [FOR REVIEW]
🧙 Author: @RantumBits on 2023-11-17
📝 Summary: This SQL model creates a table that includes information about various blockchain addresses, their corresponding decentralized exchange (DEX) names, and distinct names. This enables data analysts to analyze and query the relationships between different DEXs and their associated addresses on the Arbitrum blockchain.
MODEL: dex_polygon_addresses.sql
🟢 Added by:
🔧 PR: #4791, add dex/agg routers - polygon
🧙 Author: @RantumBits on 2023-11-17
📝 Summary: This SQL model creates a table that contains information about various blockchain addresses, their associated dex names, and distinct names. This enables data analysts to easily query and analyze the relationships between different addresses and dex platforms on the Polygon blockchain.
MODEL: dex_bnb_addresses.sql
🟢 Added by:
🔧 PR: #4793, add dex/agg routers - bnb
🧙 Author: @RantumBits on 2023-11-17
📝 Summary: This SQL model creates a table that includes information about different blockchain addresses and their corresponding decentralized exchange (DEX) names. It enables data analysts to easily query and analyze the relationships between blockchain addresses, DEX names, and distinct names associated with each address.
SECTOR: labels
toggle to see all model updates
MODEL: labels_bridges_arbitrum.sql
🟢 Added by:
🔧 PR: #4810, Polygon, Arbitrum, Optimism bridges
🧙 Author: @RantumBits on 2023-11-22
📝 Summary: This SQL model creates a table that includes information about various bridges on the Arbitrum blockchain. The table includes columns for the blockchain name, address, bridge name, category, contributor, source of data, creation and update timestamps, model name and label type. This enables data analysts to analyze and query information about these bridges on the Arbitrum blockchain.
MODEL: labels_bridges_optimism.sql
🟢 Added by:
🔧 PR: #4810, Polygon, Arbitrum, Optimism bridges
🧙 Author: @RantumBits on 2023-11-22
📝 Summary: This SQL model creates a table that includes information about various bridges on the Optimism blockchain. It provides details such as the blockchain name, address, bridge name, category, contributor, source of data, creation and update timestamps. The model also includes columns for the model name and label type associated with these bridges. This table enables data analysts to analyze and query information related to Optimism bridges efficiently.
MODEL: labels_bridges_polygon.sql
🟢 Added by:
🔧 PR: #4810, Polygon, Arbitrum, Optimism bridges
🧙 Author: @RantumBits on 2023-11-22
📝 Summary: This SQL model creates a table that includes information about various bridges on the Polygon blockchain. It provides details such as the blockchain, address, name, category, contributor, source, creation date and time stamp of each bridge. The model_name and label_type columns are also included in the table. This data can be used by data analysts to analyze and understand different bridges on the Polygon network.
MODEL: labels_bridges.sql
🟠 Modified by:
🔧 PR: #4827, Polygon, Arbitrum, Optimism bridges
🧙 Author: @RantumBits on 2023-11-22
📝 Summary: In this SQL model, several references to bridge models are added. The new bridges that were added include 'labels_bridges_arbitrum', 'labels_bridges_polygon', and 'labels_bridges_optimism'. The SELECT statement remains the same.
🔧 PR: #4827, Base bridges & move Ethereum bridge addresses
🧙 Author: @RantumBits on 2023-11-21
📝 Summary: In this SQL model, three bridge models are referenced: 'labels_bridges_ethereum', 'labels_bridges_fantom', and 'labels_bridges_base'. The SELECT statement retrieves all columns from these bridge models.
MODEL: labels_bridges_base.sql
🟢 Added by:
🔧 PR: #4827, Base bridges & move Ethereum bridge addresses
🧙 Author: @RantumBits on 2023-11-21
📝 Summary: This SQL model creates a table that includes information about various blockchain addresses. It provides details such as the blockchain name, address, name of the entity associated with the address, category, contributor, source of data, creation and update timestamps. The model_name and label_type columns are also included in this table. This enables data analysts to analyze and query information related to these blockchain addresses for further analysis or reporting purposes.
SECTOR: tokens
toggle to see all model updates
MODEL: tokens_bnb_bep20.sql
🟠 Modified by:
🔧 PR: #4836, Add token SnBNB
🧙 Author: @Leonardohhh on 2023-11-21
📝 Summary: A new row has been added to the SQL model. The row includes a contract address, symbol, and decimal value for a token called 'SnBNB'.
MODEL: tokens_erc20.sql
🟠 Modified by:
🔧 PR: #4798, Add Zora to Tokens Tables
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: The reference models that were added or removed in the diff are:
MODEL: tokens_native.sql
🟠 Modified by:
🔧 PR: #4798, Add Zora to Tokens Tables
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: The main logic added in this SQL model is the inclusion of two additional rows to the result set. The rows represent 'base' and 'zora' chains, with their corresponding symbol, price_symbol, price_address, and decimals values. These new rows are appended to the existing list of chains (ethereum, optimism, polygon, arbitrum,and avalanche_c) along with their respective details.
MODEL: tokens_nft.sql
🟠 Modified by:
🔧 PR: #4798, Add Zora to Tokens Tables
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: In this diff, a new reference to the 'tokens_zora_nft' model was added. This means that a new table or view called 'zora' is being referenced in the SQL query.
MODEL: tokens_zora_erc20.sql
🟢 Added by:
🔧 PR: #4798, Add Zora to Tokens Tables
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This SQL model creates a temporary table called 'temp_table' with columns for contract_address, symbol, and decimals. It selects the values from this table and returns the contract address, symbol, and decimal values. This model enables data analysts to retrieve specific information about contracts such as their addresses, symbols (e.g., currency codes), and decimal places used for calculations or formatting purposes.
MODEL: tokens_zora_nft.sql
🟢 Added by:
🔧 PR: #4798, Add Zora to Tokens Tables
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This SQL model creates a query that retrieves information about contract addresses, names, symbols, and standards from two different tables: 'tokens_zora_nft_standards' and 'tokens_zora_nft_curated'. It enables data analysts to compare the data between these tables based on the contract address. The commented out section suggests a potential additional join with another table called 'tokens_zora_nft_bridged_mapping', but it is currently not active in this model.
MODEL: tokens_zora_nft_curated.sql
🟢 Added by:
🔧 PR: #4798, Add Zora to Tokens Tables
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This SQL model creates a temporary table called 'temp_table' with columns for contract_address, name, and symbol. It selects the values from this table and returns the contract address, name, and symbol. This model enables data analysts to retrieve information about contracts such as their addresses, names, and symbols.
MODEL: tokens_zora_nft_standards.sql
🟢 Added by:
🔧 PR: #4798, Add Zora to Tokens Tables
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This dbt SQL model creates a query that selects the contract address and the maximum token standard for each block time from the 'nft_zora_transfers' table. It also includes an optional filter to only consider data from the past 7 days if running in incremental mode. The results are grouped by contract address. This model enables data analysts to analyze and aggregate NFT transfer data based on different token standards over time.
MODEL: tokens_polygon_erc20.sql
🟠 Modified by:
🔧 PR: #4845, polygon tokens
🧙 Author: @RantumBits on 2023-11-21
📝 Summary: The added token symbols are: COMP, GIT, PLA, ROUTE, WOO, CHAMP,
MAKERX,MST,XEND,DINO,SFF,
SNX,GRT,IRON
STG
TRUEHN
VAL
SECTOR: prices
toggle to see all model updates
MODEL: prices_tokens.sql
🟠 Modified by:
🔧 PR: #4831, Add WETH price for Zora Network
🧙 Author: @hildobby on 2023-11-21
📝 Summary: The reference models that were added or removed in the given diff are: prices_zora_tokens.
MODEL: prices_bnb_tokens.sql
🟠 Modified by:
🔧 PR: #4836, Add token SnBNB
🧙 Author: @Leonardohhh on 2023-11-21
📝 Summary: The token symbols that were added or removed are: GFT, SnBNB
MODEL: prices_polygon_tokens.sql
🟠 Modified by:
🔧 PR: #4845, polygon tokens
🧙 Author: @RantumBits on 2023-11-21
📝 Summary: The token symbols that were added or removed are: GTC
SECTOR: safe
toggle to see all model updates
MODEL: safe_arbitrum_eth_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the
amount_usdcolumn, which is derived by multiplying thepricefrom a separate source with theamount_raw. The model also includes two subqueries that select data from different tables and join them based on certain conditions. Additionally, there are conditional statements to filter data based on whether it's an initial query or incremental query.MODEL: safe_avalanche_c_avax_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the USD amount for each transaction. This is done by joining the existing query with a subquery that calculates the USD amount using a price table. The subquery selects all columns from the original query and adds an additional column 'amount_usd' which is calculated as 'price * amount_raw / 1e18'. The subquery result is then joined with a left join to fetch corresponding prices based on symbol and block time.
MODEL: safe_base_eth_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the amount in USD. This is done by joining the existing query with a subquery that calculates the amount_usd using a price conversion formula. The subquery selects additional columns and aliases them as 'base' and 'ETH'. A left join is then performed on another source table to retrieve the corresponding price based on symbol and block time.
MODEL: safe_bnb_bnb_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the USD amount for each transaction. This is done by joining the existing query with a subquery that calculates the USD amount using a left join on a price table. The price is multiplied by the raw amount divided by 1e18 to get the USD value.
MODEL: safe_celo_celo_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the amount in USD. This is done by multiplying the price (retrieved from a separate source) with the raw amount. The result is stored as 'amount_usd'. Additionally, a subquery was introduced to combine two sets of data using UNION ALL and perform similar calculations for both sets.
MODEL: safe_ethereum_eth_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the USD amount for each transaction. This is done by joining the existing query with a subquery that calculates the USD price based on symbol and block time. The result is stored in a new column called 'amount_usd'.
MODEL: safe_gnosis_safes.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is a select statement that retrieves data from the 'gnosis' blockchain. It selects the blockchain name, address, creation version based on certain conditions, block date and month, creation time and transaction hash. The data is retrieved from two tables using a join operation and filtered based on various conditions such as success status, call type, input values, gas used etc. There are also conditional statements for incremental or initial query optimization.
MODEL: safe_gnosis_xdai_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the
amount_usdcolumn, which is derived by multiplying thepricefrom a separate source with theamount_raw. Additionally, there are two new subqueries that retrieve data from different sources and join them together using union all. The first subquery retrieves data from the 'gnosis' source and joins it with 'safe_gnosis_safes'. The second subquery retrieves data from 'xdai_gnosis' source and joins it with 'safe_gnosis_safes'. Finally, a left join is performed to fetch USD prices based on symbol and block time.MODEL: safe_goerli_eth_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the USD amount for each transaction. This is done by joining the existing query with a subquery that calculates the USD amount using a price table. The subquery also includes additional columns to specify blockchain and symbol information.
MODEL: safe_optimism_eth_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The added logic in the SQL model includes:
MODEL: safe_polygon_matic_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the USD amount for each transaction. This is done by joining the existing query with a subquery that calculates the USD amount using a price conversion factor. The subquery also includes additional columns to identify the blockchain and symbol of each transaction.
MODEL: safe_native_transfers_all.sql
🟢 Added by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: This SQL model creates a unified view of native transfers across multiple blockchains. It combines data from various transfer models for different blockchain symbols, addresses, block dates and times, amounts in raw and USD values, transaction hashes, and trace addresses. This enables data analysts to easily analyze and compare native transfers across different blockchains in a single query result.
MODEL: safe_transactions_all.sql
🟢 Added by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: This SQL model creates a unified view of transaction data from various blockchain networks. It combines transaction information from different models representing different blockchains into a single result set, allowing data analysts to analyze and compare transactions across multiple networks.
MODEL: safe_zksync_eth_transfers.sql
🟠 Modified by:
🔧 PR: #4844, Add combined spells to safes
🧙 Author: @alicecha on 2023-11-22
📝 Summary: The main logic added in this SQL model is the calculation of the amount in USD. This is done by joining the existing query with a subquery that calculates the amount_usd using a price conversion formula. The subquery also includes additional columns for blockchain and symbol. Additionally, a left join is performed to include prices from another data source based on matching symbols and block time intervals.
SECTOR: goosefx
toggle to see all model updates
MODEL: goosefx_ssl_v2_solana_trades.sql
🟢 Added by:
🔧 PR: #4850, add goosefx to solana dex
🧙 Author: @andrewhong5297 on 2023-11-22
📝 Summary: This SQL model creates a dataset that captures swap transactions on the Solana blockchain. It includes information such as the project, version, block time, token pair, trade source, token bought and sold amounts and symbols. It also calculates the USD value of each transaction based on current prices. The model enables data analysts to analyze swap activity and track trading volumes in USD for different tokens pairs on Solana.
SECTOR: _sector
toggle to see all model updates
MODEL: dex_base_base_trades.sql
🟠 Modified by:
🔧 PR: #4837, Add aerodrome to
dex.trades_beta🧙 Author: @tomfutago on 2023-11-22
📝 Summary: In this diff, a new reference to the model 'aerodrome_base_base_trades' was added to the list of base models. This means that data from both 'uniswap_v3_base_base_trades' and 'aerodrome_base_base_trades' will be included in the final result set.
MODEL: aerodrome_base_base_trades.sql
🟢 Added by:
🔧 PR: #4837, Add aerodrome to
dex.trades_beta🧙 Author: @tomfutago on 2023-11-22
📝 Summary: This SQL model creates a table called 'uniswap_compatible_v2_trades' that enables data analysts to analyze trades on the Uniswap V2 decentralized exchange. It pulls data from two sources, 'Pair_evt_Swap' and 'Factory_evt_PairCreated', using the specified blockchain, project, and version parameters. The table includes information about the trading pairs ('pool') involved in each trade.
MODEL: nft_old_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Add polygon mooar nft models
🧙 Author: @BennyFeng on 2023-11-22
📝 Summary: The model added references to the tables 'mooar_polygon_events', 'oneplanet_polygon_events', 'opensea_v3_arbitrum_events', and 'opensea_v4_arbitrum_events'.
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this SQL model is the column wrangling to convert the old schema to the new base_trades schema. It renames some columns, adds new columns with default values, and modifies some column values based on conditions. The final result is a SELECT statement that retrieves data from multiple nft_models and applies filters to remove duplicate rows based on duplicates_rank column value.
MODEL: mooar_polygon_events.sql
🟢 Added by:
🔧 PR: #4835, Add polygon mooar nft models
🧙 Author: @BennyFeng on 2023-11-22
📝 Summary: This SQL model creates a view that allows data analysts to retrieve all columns from the 'trades' table. It enables them to easily access and analyze trade data for further analysis and reporting purposes.
MODEL: nftearth_optimism_events.sql
🟠 Modified by:
🔧 PR: #4835, Add polygon mooar nft models
🧙 Author: @BennyFeng on 2023-11-22
📝 Summary: The main logic added in this diff is the change of the source function from 'seaport_fork_trades' to 'seaport_v3_fork_trades'. This change specifies that the trades data should be sourced from a different version of Seaport on the Optimism blockchain.
MODEL: oneplanet_polygon_events.sql
🟠 Modified by:
🔧 PR: #4835, Add polygon mooar nft models
🧙 Author: @BennyFeng on 2023-11-22
📝 Summary: The main logic added in this diff is the change of the source function from 'seaport_fork_trades' to 'seaport_v3_fork_trades'. This change is made for the trades CTE and specifies that it should use data from the Polygon blockchain, specifically from sources 'polygon' and 'oneplanet_polygon'.
MODEL: quix_seaport_optimism_events.sql
🟠 Modified by:
🔧 PR: #4835, Add polygon mooar nft models
🧙 Author: @BennyFeng on 2023-11-22
📝 Summary: The main logic added in this diff is the change of the source table for the 'trades' CTE. The previous source table was 'seaport_fork_trades' and it has been replaced with 'seaport_v3_fork_trades'. Additionally, a new parameter has been added to specify the blockchain as 'optimism' and two new sources have been included: 'optimism' transactions and 'quixotic_optimism' Seaport_evt_OrderFulfilled.
MODEL: dex_optimism_base_trades.sql
🟠 Modified by:
🔧 PR: #4769, Added woofi optimism dex
🧙 Author: @ARDev097 on 2023-11-22
📝 Summary: In this SQL model, a set of base models is defined. Two new models, 'woofi_optimism_base_trades' and 'uniswap_v3_optimism_base_trades', are added to the existing list of base models. These models are then used in a common table expression (CTE) called 'base_union'.
MODEL: woofi_optimism_base_trades.sql
🟢 Added by:
🔧 PR: #4769, Added woofi optimism dex
🧙 Author: @ARDev097 on 2023-11-22
📝 Summary: This SQL model creates a table that combines data from two different sources related to the 'woofi' project on the Optimism blockchain. It includes information such as block time, block number, token amounts bought and sold, addresses of tokens involved in the transaction, taker and maker addresses, project contract address, transaction hash, and event index. This model enables data analysts to analyze trading activity on the woofi platform on Optimism.
MODEL: nft_ethereum_aggregators_markers.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In the given SQL model, a table called 'aggregators_markers' is created with columns 'hash_marker', 'aggregator_name', and 'router_name'. The SELECT statement retrieves all rows from the table and adds a new column called 'hash_marker_size' which represents the length of the hash marker. Additionally, a transformation is applied to the hash marker column using byte array functions to reverse it and limit its size to 32 bytes.
MODEL: nft_events.sql
🟢 Added by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: This SQL model selects all columns from the 'nft_trades' table, enabling data analysts to retrieve and analyze trade data related to non-fungible tokens (NFTs). It is kept for backward compatibility purposes.
MODEL: nft_fees.sql
🟢 Added by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: This SQL model retrieves all columns from the 'nft_trades' table, enabling data analysts to access and analyze the trade data related to non-fungible tokens (NFTs). It is kept for backward compatibility purposes.
MODEL: nft_ethereum_base_trades.sql
🟢 Added by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: This SQL model creates a union of multiple NFT trade tables and filters out duplicate trades. It provides data analysts with a consolidated view of NFT trades across different projects and versions. The model includes information such as blockchain, project details, trade category (buy/sell/swap), trade type (primary/secondary), buyer/seller details, token ID, price, fees, and more. Once the base event tables are updated with transaction from/to information, the additional step for adding NFT transaction data will be removed.
MODEL: archipelago_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the logic for filtering trade events, token events, and fee events based on block time has been modified. Instead of using a fixed date range or project start date, the incremental_predicate function is used to dynamically determine the filter condition based on whether it is an incremental run or not. Additionally, new columns 'blockchain', 'project', 'project_version' are added to provide metadata about the project.
MODEL: blur_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this diff is the inclusion of additional columns in the SELECT statement. The columns 'blockchain', 'project', and 'project_version' were added with static values. Additionally, a WHERE clause was modified to use a TIMESTAMP format for the project start date variable.
MODEL: blur_seaport_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the following changes were made:
MODEL: blur_v2_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the main logic that was added is the extraction of a
royalty_fee_addressfrom three different sources (BlurPool_evt_Execution721Packed,BlurPool_evt_Execution721MakerFeePacked, andBlurPool_evt_Execution721TakerFeePacked). The condition for selecting data based on incremental or non-incremental updates was also modified. Additionally, there is a join with thetransactionstable to retrieve additional information.MODEL: collectionswap_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the main logic that was added includes:
MODEL: cryptopunks_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this diff is the selection of additional columns in the SELECT statement. Specifically, 'ethereum' as blockchain, 'cryptopunks' as project, and 'v1' as project_version were added. Additionally, evt.evt_block_time was included in the SELECT statement. The WHERE clause was also modified to exclude a specific tx_hash value and include an incremental predicate for evt.evt_block_time if it is an incremental run.
MODEL: element_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this SQL model is the inclusion of a new parameter 'blockchain' with the value 'ethereum' in the base_trades CTE. This parameter is used to filter and retrieve data from different source tables related to ERC721 and ERC1155 orders being filled.
MODEL: foundation_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the main logic that was added is the filtering of rows based on the incremental run. The previous filter using date_trunc('day', now() - interval '7' day) was replaced with a new filter using {{incremental_predicate('f.evt_block_time')}}. This change applies to multiple sources: market_evt_ReserveAuctionFinalized, market_evt_BuyPriceAccepted, market_evt_OfferAccepted, and market_evt_PrivateSaleFinalized. Additionally, some columns were added to the SELECT statement: 'ethereum' as blockchain, 'foundation' as project,'v1' as project_version.
MODEL: looksrare_seaport_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this SQL model is the inclusion of additional columns: 'blockchain', 'project', and 'project_version'. The WHERE clause was also modified to include a condition for the contract address, zone, and consideration recipient. Additionally, there is an if-else statement that checks if it's an incremental update or not. If it is incremental, a new condition based on the evt_block_time column is added using the incremental_predicate function. Otherwise, it uses a fixed start date from looksrare_seaport_start_date variable.
MODEL: looksrare_v1_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the main logic that was added is the selection of specific columns from different tables using UNION ALL. The WHERE clause was also modified to use a dynamic incremental predicate based on the 'evt_block_time' column. Additionally, new columns were added to the SELECT statement: 'blockchain', 'project', and 'project_version'.
MODEL: looksrare_v2_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the main logic that was added is the selection of additional columns: 'blockchain', 'project', and 'project_version'. The column names were also changed from 'block_time' to just 'block_number'. Additionally, a new table called 'LooksRareProtocol_evt_TakerBid' was included in the query.
MODEL: sudoswap_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this SQL model is the use of incremental updates. The
is_incremental()function is used to conditionally apply filters based on whether the run is incremental or not. If it's an incremental run, a filter is applied to only update with new swaps within the last 7 days using thecall_block_timecolumn for one part andtr.block_timefor another part. Additionally, some columns are selected and aliases are assigned to them (blockchain,project,project_version).MODEL: superrare_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this SQL model is the inclusion of different sources for the 'all_superrare_sales' CTE. Each source corresponds to a different event type related to SuperRare sales. The incremental predicate is also included, which filters the data based on the 'evt_block_time' column within a specific time range (7 days). Additionally, new columns are selected including blockchain, project, and project version information. Left joins are performed with other tables using conditions based on various columns and incremental predicates.
MODEL: x2y2_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the logic for filtering the source data has been modified. Instead of using a fixed date range, it now uses an incremental predicate function to filter based on the
evt_block_timecolumn. Additionally, new columns have been added to the SELECT statement: 'blockchain', 'project', and 'project_version'. The existing columnblock_timeis also included in the SELECT statement.MODEL: zora_v1_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this SQL model is the selection of constant values for 'blockchain', 'project', and 'project_version'. Additionally, a left join was added to the Media_evt_Transfer table with a condition that checks if the bidder address is not equal to a specific value. Finally, there are conditional statements that add incremental predicates based on block time for both bf and mt tables.
MODEL: zora_v2_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this SQL model, the main logic that was added includes:
MODEL: zora_v3_ethereum_base_trades.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The main logic added in this SQL model is the use of incremental predicates for filtering data based on the
evt_block_timecolumn. The previous condition of filtering data within the last 7 days has been replaced with a dynamic incremental predicate using{{incremental_predicate('evt_block_time')}}. Additionally, new columns have been added to the final SELECT statement: 'blockchain', 'project', and 'project_version'.MODEL: nft_base_trades.sql
🟢 Added by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: This SQL model creates a union of two tables, 'nft_ethereum_base_trades' and 'nft_old_base_trades'. It combines the data from these tables into a single result set, allowing data analysts to analyze trade information across multiple sources. The resulting table includes various columns such as blockchain, project details, transaction information, NFT details, price information, and fee details. This model enables analysts to perform queries and analysis on the combined trade data from both tables.
MODEL: nft_trades.sql
🟢 Added by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: The SQL model creates a new table or view called 'nft_trades_beta' that is likely a modified version of an existing schema. It enables data analysts to work with and analyze data related to non-fungible token (NFT) trades, providing insights into the trading activity within the NFT market.
MODEL: nft_trades_beta.sql
🟢 Added by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: This SQL model creates and enables the enrichment of non-fungible token (NFT) trades data. It utilizes a macro called 'enrich_nft_trades' to enrich the base NFT trades dataset, allowing data analysts to have access to more comprehensive information about NFT transactions for analysis purposes.
MODEL: liquidifty_bnb_events.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this diff, the main logic added is a new column called 'version' in the 'stack' table. The previous value of this column was set to null and it has been changed to 'v2'. This change indicates that a new version ('v2') is being introduced in the model.
MODEL: liquidifty_ethereum_events.sql
🟠 Modified by:
🔧 PR: #4668, Revamp NFT to new sector spell design structure
🧙 Author: @0xRobin on 2023-11-22
📝 Summary: In this diff, the following changes were made to the SQL model:
weth_addresswas set to '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2'.stackCTE, a line settingversionas null was replaced with setting it as 'v2'.v3CTE, lines casting JSON values to varbinary were replaced with using the function from_hex().MODEL: contracts_base_base_iterated_creators.sql
🟢 Added by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This SQL model creates a table called 'contracts_base_iterated_creators' that enables data analysts to analyze and track the creators of contracts in the base chain.
MODEL: contracts_base_base_starting_level.sql
🟢 Added by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This SQL model creates a table called 'contracts_base_starting_level' that enables data analysts to access information about contracts starting at the base level.
MODEL: contracts_base_contract_mapping.sql
🟢 Added by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This SQL model creates a contract mapping table that enables data analysts to map contracts in the base chain.
MODEL: contracts_base_find_self_destruct_contracts.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: The main logic added in this SQL model is a new macro called 'find_self_destruct_contracts'. It takes an optional parameter 'chain' and returns a list of self-destruct contracts. The previous version had the same macro but with the additional constraint of filtering by chain='base'. This constraint has been removed in the updated version, making it applicable to all chains.
MODEL: _schema.yml
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: [changes too large] The model _schema.yml was renamed.
MODEL: contracts_contract_creator_address_list.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: [changes too large] The model contracts_contract_creator_address_list.sql was renamed.
MODEL: contracts_contract_mapping.sql
🟢 Added by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: This SQL model creates a union of multiple contract mapping tables for different blockchain networks. It enables data analysts to query and analyze contract data across various chains in a single result set. The specific chains included in the union can be customized by uncommenting or adding additional lines in the model.
MODEL: contracts_contract_overrides.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: In this SQL model, several contract addresses and their corresponding project names were added or removed. The main logic of the changes is to update the project names for certain contract addresses on the OP Mainnet. Additionally, a new contract address and its project name 'first.lol' were added, as well as a new entry for 'Gnosis Safe' with its corresponding project name 'Safe Singleton Factory'. Lastly, an entry for WETH (Wrapped Ether) was included in the list of contracts with its respective project name.
MODEL: contracts_deterministic_contract_creators.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: In this SQL model, the following addresses and their corresponding names were added: - 0x00000000000000000000000000...8006: 'zkSync Contract Deployer' (zkSync)
MODEL: contracts_disperse_contracts.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: [changes too large] The model contracts_disperse_contracts.sql was renamed.
MODEL: contracts_predeploys.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: The main logic that was added in this SQL model is the replacement of the column 'contract_factory' with 'created_tx_hash'. Additionally, there are changes made to handle null values and join different tables for data retrieval. The final SELECT statement includes distinct values for blockchain, trace_creator_address, contract_address, contract_project (with proper case formatting), contract_name, creator_address (cast as varbinary), created_time, is_self_destruct flag and source.
MODEL: contracts_project_name_mappings.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: In the given SQL model, a new entry for 'rubic_crosschain' with the mapped name 'Rubic' has been added to the temporary table.
MODEL: contracts_self_destruct_contracts.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @MSilb7 on 2023-11-21
📝 Summary: In this diff, a new reference to the model 'contracts_optimism_find_self_destruct_contracts' was added. Additionally, the conditional statement for filtering data based on a date range was modified. The previous condition 'destructed_time >= date_trunc('day', now() - interval '7' day)' was replaced with '{{ incremental_predicate('destructed_time') }}'.
MODEL: contracts_system_predeploys.sql
🟠 Modified by:
🔧 PR: #4747, Add OP to Contracts Mapping & Overwrite Existing
🧙 Author: @msilb
Beta Was this translation helpful? Give feedback.
All reactions