📰 2023-10-03: Weekly Prophet! #4511
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 58 PRs merged from 18 wizards. Great job everyone! 🎉
We had 137 added models 🟢 and 361 modified models 🟠 for 43 Sectors.
SECTOR: dex
toggle to see all model updates
MODEL: dex_trades.sql
🟠 Modified by:
🔧 PR: #4406, Celo ubeswap
🧙 Author: @tomfutago on 2023-09-29
📝 Summary: The reference models that were added or removed in the diff are: 'ubeswap_celo_trades' was added.
🔧 PR: #4406, Add Mauve - ready for review
🧙 Author: @ra-phael on 2023-09-27
📝 Summary: The reference models that were added or removed in the diff are: aerodrome_base_trades, carbon_defi_ethereum_trades, opx_finance_optimism_trades, and mauve_trades.
🔧 PR: #4406, Added opx_finance optimism trades to dex_trades.sql
🧙 Author: @kaiblade on 2023-09-26
📝 Summary: The reference models that were added or removed in the diff are: opx_finance_optimism_trades
MODEL: dex_aggregator_trades.sql
🟠 Modified by:
🔧 PR: #4320, SPE-15 migrate
dex_aggregator.tradesto dunesql engine🧙 Author: @jeff-dude on 2023-09-29
📝 Summary: The reference models that were added are: cow_protocol_trades, oneinch_ethereum_trades, openocean_trades, paraswap_trades, lifi_trades, yield_yak_avalanche_c_trades, bebop_trades,dodo_aggregator_trade and zeroex_trade. The reference model that was removed is: odos_trade.
MODEL: dex_arbitrum_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model creates a table called 'dex_sandwiches' that enables data analysts to analyze transactions on the Arbitrum blockchain. The model sources data from the 'transactions' table in the Arbitrum database.
MODEL: dex_arbitrum_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_avalanche_c_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This dbt SQL model creates a table called 'dex_sandwiches' that pulls data from the 'transactions' table in the 'avalanche_c' blockchain. It enables data analysts to analyze and query information related to sandwich attacks in decentralized exchanges on the Avalanche network.
MODEL: dex_avalanche_c_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_base_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model creates a table called 'dex_sandwiches' that is based on the 'transactions' table from the 'base' blockchain. It enables data analysts to analyze and query data related to sandwich attacks in decentralized exchanges.
MODEL: dex_base_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_bnb_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This dbt SQL model creates a table called 'dex_sandwiches' that enables data analysts to analyze transactions in the Binance blockchain. The model sources data from the 'transactions' table in the Binance blockchain and focuses on identifying sandwich attacks within decentralized exchanges (DEX).
MODEL: dex_bnb_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_ethereum_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model creates a table called 'dex_sandwiches' that enables data analysts to analyze transactions on the Ethereum blockchain. The source of the data is the 'transactions' table from the Ethereum dataset.
MODEL: dex_ethereum_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_fantom_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This dbt SQL model creates a table called 'dex_sandwiches' that enables data analysts to analyze transactions on the Fantom blockchain. The model sources data from the 'transactions' table in the Fantom database.
MODEL: dex_fantom_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_gnosis_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This dbt SQL model creates a table called 'dex_sandwiches' that pulls data from the 'transactions' table in the 'gnosis' blockchain. It enables data analysts to analyze and gain insights into sandwich trading patterns within the specified blockchain.
MODEL: dex_gnosis_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_optimism_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This dbt SQL model creates a table called 'dex_sandwiches' that enables data analysts to analyze transactions on the Optimism blockchain. The model sources data from the 'transactions' table in the 'optimism' schema.
MODEL: dex_optimism_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_polygon_sandwiches.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model creates a table called 'dex_sandwiches' that enables data analysts to analyze transactions on the Polygon blockchain. The data for this analysis is sourced from the 'transactions' table in the Polygon database.
MODEL: dex_polygon_sandwiches_legacy.sql
🟢 Added by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: This SQL model does not create or enable anything for data analysts. It simply selects the value 1, which is a common practice to check if a database connection is working properly.
MODEL: dex_sandwiches.sql
🟠 Modified by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: In this SQL model, a new reference to 'dex_base_sandwiches' is added. The SELECT statement is modified to select all columns from each sandwiches_model. If the model is incremental, it filters the results based on block_time being within the last week. Finally, a UNION ALL operator combines the results of all sandwiches_models into one result set.
MODEL: dex_sandwiches_legacy.sql
🟠 Modified by:
🔧 PR: #4315, SPE-4 Migrate & rework
dex.sandwiches🧙 Author: @hildobby on 2023-09-27
📝 Summary: The logic that was added in this diff is a simple SELECT statement with the value 1. It seems like this change removed a complex logic that involved selecting data from multiple tables and applying some conditions.
MODEL: dex_info.sql
🟢 Added by:
🔧 PR: #4403, Create
dex.info🧙 Author: @hildobby on 2023-09-26
📝 Summary: This SQL model creates a temporary table called 'temp_table' with columns for codename, name, marketplace_type, and x_username. It populates the table with values for various decentralized exchanges (Uniswap, PancakeSwap, CurveFinance, etc.) and their corresponding usernames. This model enables data analysts to query this temporary table to retrieve information about different decentralized exchanges and their associated usernames.
SECTOR: nft
toggle to see all model updates
MODEL: nft_avalanche_c_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_base_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_bnb_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_celo_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_ethereum_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_fantom_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_gnosis_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_goerli_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_optimism_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a hardcoded SQL condition, but it has been replaced with a function call to incremental_predicate(). This indicates that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_polygon_transfers.sql
🟠 Modified by:
🔧 PR: #4502, Nft transfer models incremental macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is the change in the incremental_predicates parameter. The previous value was a specific SQL condition, but it has been replaced with a function call to incremental_predicate(). This suggests that there is now a custom function being used to determine the incremental predicates for this model.
MODEL: nft_ethereum_top_minters.sql
🟠 Modified by:
🔧 PR: #4503, Migrate nft_ethereum_top_minters
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The added logic in this SQL model includes:
count of records as no_minted,and max block_time value grouped by nft_contract_address and buyer. If the CTE is not available (else), it uses a similar query directly on the 'nft_mints' table.
MODEL: nft_transfers.sql
🟠 Modified by:
🔧 PR: #4487, Incremental predicate macro
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this diff is a conditional statement that filters the data based on the block_time column. If it's an incremental run, the WHERE clause is modified to include only records with a block_time greater than or equal to 7 days ago. Otherwise, all records from the nft_model are included in the result set.
MODEL: nft_ethereum_wallet_metrics.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: The main logic added in this SQL model is the conversion of certain columns from their original data types to specific data types. Additionally, there are some changes made to the conditions in the WHERE clause for filtering rows based on specific criteria. Finally, calculations have been added for various metrics such as win percentage, loss percentage, breakeven percentage, ROI (return on investment), and total profit/loss values.
MODEL: nft_ethereum_metadata_art_blocks_collections.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: [changes too large] The model nft_ethereum_metadata_art_blocks_collections.sql was modified.
MODEL: nft_ethereum_metadata_braindrops.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: The diff of the SQL model shows that a VALUES clause was added to select specific columns from a temporary table. The VALUES clause contains multiple rows, each representing a set of values for the corresponding columns. The added rows include contract_address, project_id, project_id_base_value, collection_name, artist_name, and art_collection_unique_id.
MODEL: nft_ethereum_metadata_bright_moments.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: [changes too large] The model nft_ethereum_metadata_bright_moments.sql was modified.
MODEL: nft_ethereum_metadata_fellowship_gallery.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: [changes too large] The model nft_ethereum_metadata_fellowship_gallery.sql was modified.
MODEL: nft_ethereum_metadata_mirage_gallery_curated.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: The main logic added in this SQL model is a temporary table called 'temp_table' that contains values for contract_address, project_id, project_id_base_value, collection_name, artist_name, mirage_project_name, and art_collection_unique_id. These values are inserted into the temp_table using the VALUES clause. The original lines starting with '-' were removed and replaced with new lines starting with '+', but the overall logic remains unchanged.
MODEL: nft_ethereum_metadata_proof_grails_i.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: [changes too large] The model nft_ethereum_metadata_proof_grails_i.sql was modified.
MODEL: nft_ethereum_metadata_proof_grails_ii.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: [changes too large] The model nft_ethereum_metadata_proof_grails_ii.sql was modified.
MODEL: nft_ethereum_metadata_verse.sql
🟠 Modified by:
🔧 PR: #4446, Migrate
nft_ethereum_metadatatables🧙 Author: @hildobby on 2023-09-28
📝 Summary: The main logic added in this SQL model is a temporary table called 'temp_table' that contains the columns contract_address, project_id, project_id_base_value, collection_name, artist_name, and art_collection_unique_id. The values for these columns are inserted into the temp_table using a VALUES statement with two rows of data.
MODEL: nft_lending.sql
🟠 Modified by:
🔧 PR: #4396, Enrich NFT.lending spell & introduce new columns - ready for review
🧙 Author: @henrystats on 2023-09-27
📝 Summary: In this diff of the dbt SQL model, a new table called 'lending_category' was added. Additionally, the column 'address' was removed and two new columns, 'borrower' and 'lender', were added. The other changes in the model include adding or removing various tables and columns related to blockchain data such as amount_usd, token_standard, evt_type, amount_original, amount_raw,and collateral_currency_symbol.
MODEL: nft_ethereum_native_mints.sql
🟠 Modified by:
🔧 PR: #4354, Migrate NFT Mints - Ready for review
🧙 Author: @henrystats on 2023-09-27
📝 Summary: The main logic added in this SQL model is the calculation of various fields related to NFT transactions. This includes grouping NFTs by address, calculating the number of NFTs minted in each transaction, and determining trade type and category. It also involves joining multiple tables to retrieve additional information such as token details, prices, and aggregators. The final result is filtered based on certain conditions and ranked based on amount_usd before selecting only the top-ranked rows for further analysis.
MODEL: nft_mints.sql
🟠 Modified by:
🔧 PR: #4354, Migrate NFT Mints - Ready for review
🧙 Author: @henrystats on 2023-09-27
📝 Summary: In this SQL model, the logic for selecting data from different tables has been modified. The 'project_mints' table now includes additional columns such as 'block_month' and 'evt_index'. The condition for filtering rows in the WHERE clause has also been changed to filter by evt_type = 'Mint' and block_time >= date_trunc('day', now() - interval '7' Day). Additionally, a new table called 'native_mints' has been added with its own set of columns and join conditions.
MODEL: nft_optimism_native_mints.sql
🟠 Modified by:
🔧 PR: #4354, Migrate NFT Mints - Ready for review
🧙 Author: @henrystats on 2023-09-27
📝 Summary: In this SQL model, the logic for calculating the number of NFTs minted per transaction has been modified. The previous logic used a CTE called 'nfts_per_tx' to calculate the sum of NFT amounts grouped by transaction hash. The new logic uses a temporary table called 'nfts_per_tx_tmp' to perform the same calculation and then creates another CTE called 'nfts_per_tx' that modifies one column in this temporary table. Additionally, a new SELECT statement is added at the end which includes various columns from different tables and applies ranking based on amount_usd in descending order using ROW_NUMBER() function with PARTITION BY clause.
MODEL: nft_ethereum_collection_stats.sql
🟠 Modified by:
🔧 PR: #4339, Migrate some nft ethereum spells - Ready for review
🧙 Author: @henrystats on 2023-09-27
📝 Summary: In this SQL model, the following changes were made:
MODEL: nft_ethereum_top_sales.sql
🟠 Modified by:
🔧 PR: #4339, Migrate some nft ethereum spells - Ready for review
🧙 Author: @henrystats on 2023-09-27
📝 Summary: The main logic added in this diff is the change in the condition for the 'number_of_items' column. Previously, it was checking if it equals 1, but now it checks if it equals UINT256 '1'. This suggests a change in data type or representation for that column.
MODEL: nft_ethereum_wallet_pnl.sql
🟠 Modified by:
🔧 PR: #4339, Migrate some nft ethereum spells - Ready for review
🧙 Author: @henrystats on 2023-09-27
📝 Summary: In this SQL model, the changes made include replacing the interval value from '1 week' to '7 Day', and changing the number_of_items condition from a plain integer comparison to a UINT256 comparison with value '1'. These changes are applied in multiple places within the model. The logic remains focused on selecting trades that meet certain criteria such as block time, blockchain type, currency symbol, non-null original amount, and buyer not equal to seller. The results are grouped based on specific columns.
MODEL: nft_marketplaces_info.sql
🟢 Added by:
🔧 PR: #4402, Create
nft.info🧙 Author: @hildobby on 2023-09-26
📝 Summary: This SQL model creates a temporary table that contains information about various marketplaces in the NFT space. The table includes columns for the marketplace's codename, name, marketplace type (direct or aggregator), and an optional username associated with the marketplace. This model enables data analysts to easily query and analyze data related to these marketplaces.
SECTOR: labels
toggle to see all model updates
MODEL: labels_airdrop.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: The added logic in this SQL model is creating a set of models called 'airdrop_labels_models' which includes three references to other models. Then, a SELECT statement is used to retrieve data from each model in the set and combine them using UNION ALL. The resulting dataset includes columns for blockchain, address, name, category, contributor, source, created_at and updated_at timestamps as well as additional columns for model_name and label_type.
MODEL: labels_airdrop_1_receivers_optimism.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: The main logic added in this SQL model is a change in the data source. The previous version used a reference to
airdrop_optimism_addresses_1while the updated version usesdune_uploadas the source andop_airdrop1_addresses_detailed_listas the table name. Additionally, there was a change in how timestamps are specified, withtimestamp('2022-09-29')being replaced byTIMESTAMP '2022-09-29'.MODEL: labels_airdrop_1_receivers_optimism_legacy.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: The main logic that was added in this SQL model is a simple SELECT statement with the value 1 being selected.
MODEL: labels_airdrop_2_receivers_optimism.sql
🟢 Added by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: This SQL model creates a dataset that enables data analysts to track and analyze the details of addresses receiving an airdrop in the blockchain. It includes information such as the address, name, category, contributor, source query used for extraction, creation and update timestamps. The model is named 'op_airdrop_2_receivers' and uses a label type called 'persona'.
MODEL: labels_airdrop_3_receivers_optimism.sql
🟢 Added by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: This SQL model creates a dataset that includes information about blockchain addresses receiving an optimism (OP) airdrop. It provides details such as the address, name of the receiver, category of the transaction, contributor's name, source query used to fetch data, creation and update timestamps. The model is named 'op_airdrop_3_receivers' and uses a label type called 'persona'.
MODEL: labels_nft.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: The main logic that was added is a closing parenthesis at the end of the SQL model. The lines with '-' indicate that this closing parenthesis was removed in the previous version.
MODEL: labels_nft_smart_trader_roi_eth.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: The diff of the SQL model shows that there were no changes made.
MODEL: labels_addresses.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: The reference models that were added or removed in the diff are: None.
MODEL: labels_addresses_legacy.sql
🟠 Modified by:
🔧 PR: #3809, Finalize labels/addresses/ migration
🧙 Author: @Hosuke on 2023-10-02
📝 Summary: In this diff, the reference to 'labels_airdrop_legacy' has been removed from the SQL model.
MODEL: labels_dex.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: The diff shows that the 'labels_trader_portfolios' model was removed from the list of dex_models.
MODEL: labels_arbitrage_traders_ethereum.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: In this SQL model, the diff shows that the source tables for Uni V2 and Uni V3 pools have been changed to use variables. Additionally, a list of error contracts has been replaced with a VALUES statement containing specific addresses. The SELECT statement at the end has also been modified to change some string values from double quotes to single quotes and update timestamp syntax. Finally, there are changes in column names and values in the final SELECT query.
MODEL: labels_dex_aggregator_traders.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: In this SQL model, the changes made include:
MODEL: labels_trader_platforms.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: The main logic added in this SQL model is the use of
ARRAY_AGGfunction to concatenate and aggregate values from theprojectcolumn. The result is then joined into a string using,as a separator, and appended with the text ' User'. Some string values are also changed from double quotes to single quotes, and there's an additional condition in the WHERE clause to filter out null addresses.MODEL: labels_average_trade_values.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: In this SQL model, the logic for selecting the name column has been modified. If the average_trade_value is greater than 400, it will be labeled as '$400-$1k avg. DEX trade value', otherwise it will be labeled as '<=$400 avg. DEX trade value'. The values of category, contributor, source, created_at and model_name columns have been changed from double quotes to single quotes. Additionally, a new column called updated_at has been added with the current timestamp and label_type has replaced usage in one of the columns.
MODEL: labels_trader_age.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: The main logic added in this SQL model is the calculation of trader age using the
date_difffunction instead ofdatediff. The result is then used to categorize traders as either '1 week old DEX trader' or 'less than 1 week old DEX trader'. Some string values and timestamps were also updated.MODEL: labels_trader_dex_diversity.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: In this SQL model, the grouping logic for the columns 'taker' and 'blockchain' was modified. The column names in the SELECT statement were also changed to use single quotes instead of double quotes. Additionally, a cast function was added to convert the 'dex_diversity' column into a varchar type. The values for some columns like name, category, contributor, source, created_at were updated with new values or expressions using concatenation and timestamp functions.
MODEL: labels_trader_frequencies.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: The main logic added in this SQL model is a case statement to calculate the 'trades_per_day' metric. If the difference between the minimum and maximum block dates is 0, then it sets 'trades_per_day' as null. Otherwise, it calculates the count of distinct transaction hashes divided by the difference in days between min and max block dates. Additionally, there are changes made to some column values like 'dex', 'gentrexha', etc., and some columns have been removed from final select query.
MODEL: labels_trader_portfolios_ethereum.sql
🟠 Modified by:
🔧 PR: #4205, Labels dex persona migration
🧙 Author: @Hosuke on 2023-09-29
📝 Summary: In this SQL model, the changes made include replacing double quotes with single quotes for string values. The 'blockchain' column now has the value 'ethereum' instead of 'ethereum'. Similarly, the 'category', 'contributor', and 'source' columns have been updated to use single quotes. The timestamp function has been replaced with a timestamp value directly ('2022-12-15'). Additionally, the model_name and label_type columns now have string values enclosed in single quotes.
SECTOR: tokens
toggle to see all model updates
MODEL: tokens_ethereum_rebase.sql
🟠 Modified by:
🔧 PR: #4500, SPE-138 Migrate rebase tokens
🧙 Author: @couralex6 on 2023-10-03
📝 Summary: The main logic added in this SQL model is a SELECT statement that retrieves the contract_address and symbol columns from a temporary table. The temporary table is created using the VALUES clause, where multiple rows are inserted with contract addresses and symbols. Each row consists of a contract address (in hexadecimal format) enclosed in parentheses, followed by its corresponding symbol enclosed in single quotes ('$' prefix).
MODEL: tokens_fantom_rebase.sql
🟠 Modified by:
🔧 PR: #4500, SPE-138 Migrate rebase tokens
🧙 Author: @couralex6 on 2023-10-03
📝 Summary: The main logic of the changes in this SQL model is that the
LOWER()function was removed from thecontract_addresscolumn in the SELECT statement. Additionally, single quotes were removed from around the contract address value and it was changed to a numeric format instead of a string format. The rest of the code remains unchanged.MODEL: tokens_ethereum_erc20_stablecoins.sql
🟠 Modified by:
🔧 PR: #4341, SPE-93 Migrate cow_protocol models downstream of dex_trades
🧙 Author: @couralex6 on 2023-10-02
📝 Summary: The main logic added in this SQL model is the removal of the LOWER function applied to the 'contract_address' column in the SELECT statement. The values for 'contract_address', 'symbol', 'decimals', and 'name' are now selected directly from a temporary table created using VALUES.
MODEL: tokens_fantom_erc20_stablecoins.sql
🟠 Modified by:
🔧 PR: #4341, SPE-93 Migrate cow_protocol models downstream of dex_trades
🧙 Author: @couralex6 on 2023-10-02
📝 Summary: The main logic added in this SQL model is a SELECT statement that retrieves the contract_address, symbol, decimals, and name columns from a temporary table. The temporary table is created using the VALUES clause to insert multiple rows with corresponding values for each column. The LOWER function used in the original model to convert contract_address to lowercase has been removed in the updated version.
MODEL: tokens_ethereum_erc20.sql
🟠 Modified by:
🔧 PR: #4386, Add Mauve - ready for review
🧙 Author: @ra-phael on 2023-09-27
📝 Summary: The token symbols that were added or removed are: Added: LsETH
MODEL: tokens_ethereum_erc20_legacy.sql
🟠 Modified by:
🔧 PR: #4386, Add Mauve - ready for review
🧙 Author: @ra-phael on 2023-09-27
📝 Summary: A new row was added to the temporary table. The contract address '0x8c1BEd5b9a0928467c9B1341Da1D7BD5e10b6549' with symbol 'LsETH' and decimals 18 was inserted into the table.
MODEL: tokens_base_erc20.sql
🟠 Modified by:
🔧 PR: #4345, OP & BASE Static Updates
🧙 Author: @MSilb7 on 2023-09-26
📝 Summary: The token symbols that were added or removed are: AERO, USDC
MODEL: tokens_optimism_erc20_curated.sql
🟠 Modified by:
🔧 PR: #4345, OP & BASE Static Updates
🧙 Author: @MSilb7 on 2023-09-26
📝 Summary: In the given SQL model, several rows were added to the 'raw_token_list' CTE. Each row represents a token with its contract address, symbol, decimals, and token type. The tokens that were added include VELO, TAROT, GNODE, EXA, axlUSDC,NEXT ,UNIDX ,msUSD,YFX ,MMY ,msOP,D2D,COC,bwAJNA,ePendle,
FPIS,NFTE,wOpenX 1INCH crvUSD SYNTH EQB FPI GROW YFI
MODEL: tokens_optimism_erc20_curated_legacy.sql
🟠 Modified by:
🔧 PR: #4345, OP & BASE Static Updates
🧙 Author: @MSilb7 on 2023-09-26
📝 Summary: In this SQL model, three rows were added to the
raw_token_listCTE. The new rows include information about tokens with contract addresses '0x9560e827aF36c94D2Ac33a39bCE1Fe78631088Db', '0x1f514a61bcde34f94bc39731235690ab9da737f7', and '0x5976d4c3bcfc1c5f90ab1419d7f3ddf109cea35a'. These tokens have symbols 'VELO', 'TAROT', and 'GNODE' respectively, with 18 decimals each. They are classified as 'underlying' tokens based on their token type.MODEL: tokens_optimism_nft_curated.sql
🟠 Modified by:
🔧 PR: #4345, OP & BASE Static Updates
🧙 Author: @MSilb7 on 2023-09-26
📝 Summary: A new contract address and name, 'XEN Torrent', was added to the temporary table in the SQL model.
SECTOR: aave
toggle to see all model updates
MODEL: aave_ethereum_proposals.sql
🟠 Modified by:
🔧 PR: #4484, Dao votes proposals
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this SQL model is the calculation of votes for and against a certain proposition. It calculates the number of voters, total votes for, total votes against, and total abstained votes. It also calculates the participation percentage based on the total supply. Additionally, it determines whether a proposition is executed, canceled, pending or active based on certain conditions involving block times and latest block numbers.
MODEL: aave_ethereum_votes.sql
🟠 Modified by:
🔧 PR: #4484, Dao votes proposals
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this SQL model is a common table expression (CTE) named 'cte_sum_votes' that calculates the sum of voting power divided by 1e18 for each ID from the source table 'AaveGovernanceV2_evt_VoteEmitted'. The CTE is then used to calculate the votes, votes share, token symbol, token address, votes value in USD, voter address and vote support status.
SECTOR: compound
toggle to see all model updates
MODEL: compound_v2_ethereum_proposals.sql
🟠 Modified by:
🔧 PR: #4450, Dao votes proposals
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this SQL model is the creation of two common table expressions (CTEs) named 'cte_support' and 'cte_sum_votes'. The 'cte_support' CTE calculates the votes for and against each proposal by voter, while the 'cte_sum_votes' CTE calculates various vote totals for each proposal. Additionally, a CASE statement is added to determine the status of each proposal based on certain conditions such as execution, cancellation, active status, or being queued.
🔧 PR: #4450, SPE-134 Migrate compound
🧙 Author: @couralex6 on 2023-09-29
📝 Summary: In this SQL model, the following changes were made:
MODEL: compound_v2_ethereum_votes.sql
🟠 Modified by:
🔧 PR: #4450, Dao votes proposals
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: The main logic added in this SQL model is a common table expression (CTE) named 'cte_sum_votes' that calculates the sum of votes for each proposalId. The SELECT statement then retrieves various columns including blockchain, project, version, votes, votes_share, token_symbol, token_address, votes_value_usd and voter_address from different tables. There is also a CASE statement to determine if the support value is 0 or not.
🔧 PR: #4450, SPE-134 Migrate compound
🧙 Author: @couralex6 on 2023-09-29
📝 Summary: In this SQL model, the following changes were made: - Added a new column called 'block_month' which extracts the month from 'evt_block_time'.
MODEL: compound_v2_ethereum_borrow.sql
🟠 Modified by:
🔧 PR: #4450, SPE-134 Migrate compound
🧙 Author: @couralex6 on 2023-09-29
📝 Summary: In this SQL model, the following changes were made: - The data type of the 'repayer' and 'liquidator' columns in the 'borrows', 'repays', and 'liquidations' CTEs was changed from varchar(5) to VARBINARY.
MODEL: compound_v2_ethereum_ctokens.sql
🟠 Modified by:
🔧 PR: #4450, SPE-134 Migrate compound
🧙 Author: @couralex6 on 2023-09-29
📝 Summary: The main logic added in this SQL model is a select statement that retrieves the asset symbol, ctoken address, asset address, and decimals mantissa from a set of values. The values include various assets such as AAVE, BAT, COMP, DAI and their corresponding addresses and decimal values. Some assets like cETH don't have an underlying asset but are chosen based on prices.usd.
MODEL: compound_v2_ethereum_supply.sql
🟠 Modified by:
🔧 PR: #4450, SPE-134 Migrate compound
🧙 Author: @couralex6 on 2023-09-29
📝 Summary: The main logic added in this SQL model is the calculation of the 'amount' and 'usd_amount' columns for both mints and redeems. The previous code used explicit casting to calculate these values, but it has been simplified by directly dividing the mintAmount or redeemAmount by decimals_mantissa and then multiplying it by price. Additionally, a new column called 'block_month' has been added to capture the month from evt_block_time using date_trunc function with 'month' parameter.
SECTOR: ens
toggle to see all model updates
MODEL: ens_ethereum_proposals.sql
🟠 Modified by:
🔧 PR: #4484, Dao votes proposals
🧙 Author: @aalan3 on 2023-10-03
📝 Summary: In this SQL model, the main logic that was added includes:
Beta Was this translation helpful? Give feedback.
All reactions