📰 2023-10-06: Weekly Prophet! #4545
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 21 wizards. Great job everyone! 🎉
We had 44 added models 🟢 and 354 modified models 🟠 for 50 Sectors.
SECTOR: dex
toggle to see all model updates
MODEL: dex_aggregator_trades.sql
🟠 Modified by:
🔧 PR: #4194, [READY TO REVIEW] Add kyberswap to sector dex_aggregator
🧙 Author: @nhd98z on 2023-10-05
📝 Summary: The reference models that were added or removed in the given diff are:
Added: kyberswap_aggregator_trades
Removed: bebop_trades, dodo_aggregator_trades, zeroex_trades
MODEL: dex_solana_trades.sql
🟢 Added by:
🔧 PR: #4480, Solana dex.trades (Lifinity v1/v2, Raydium v3, Phoenix v1, orca)
🧙 Author: @andrewhong5297 on 2023-10-05
📝 Summary: This SQL model creates a union of multiple Solana decentralized exchange (DEX) tables, including Orca Whirlpool Trades, Raydium V3 Trades, Phoenix V1 Trades, Lifinity V1 Trades, and Lifinity V2 Trades. It selects various columns related to trade details such as blockchain information, project details, token symbols and amounts bought/sold in different currencies. This model enables data analysts to analyze and compare trading activities across these DEXes on the Solana blockchain.
MODEL: dex_arbitrum_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: The main logic added in this SQL model is the definition of a new dbt table called 'dex_sandwiches'. It specifies that the data for this table will come from the 'transactions' source in the 'arbitrum' blockchain.
MODEL: dex_avalanche_c_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: In this diff, the
dex_sandwichesmodel is being modified. Theblockchainparameter is set to'avalanche_c', and a source named'transactions'from the'avalanche_c'database is added.MODEL: dex_base_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: In this diff, the
dex_sandwichesmodel is being modified. Theblockchainparameter is set to'base', and a source named'transactions'from the'base'schema is added as an input for this model.MODEL: dex_bnb_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: In this diff, the
dex_sandwichesmodel is being modified. Theblockchainparameter is set to'bnb', and a source named'transactions'from the'bnb'blockchain is added.MODEL: dex_ethereum_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: In this diff, the
dex_sandwichesmodel is being modified. Theblockchainparameter is set to 'ethereum' and a source named 'transactions' from the ethereum blockchain is added.MODEL: dex_fantom_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: In this diff, the
dex_sandwichesmodel is being modified. Thetransactionssource from the Fantom blockchain is being removed.MODEL: dex_gnosis_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: The main logic added in this SQL model is the definition of a new table called 'dex_sandwiches'. It includes a parameter for the blockchain type and retrieves data from the 'transactions' source in the 'gnosis' schema.
MODEL: dex_optimism_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: In this diff, the
dex_sandwichesmodel is being modified. Theblockchainparameter is set to 'optimism' and a source named 'transactions' from the 'optimism' database is added.MODEL: dex_polygon_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: In this diff, the
dex_sandwichesmodel is being modified. Theblockchainparameter is set to'polygon', and a source named'transactions'from the'polygon'database is added as a dependency for this model.MODEL: dex_sandwiches.sql
🟠 Modified by:
🔧 PR: #4462, Some dex.sandwiches fixes
🧙 Author: @hildobby on 2023-10-03
📝 Summary: The main logic added in this SQL model is the selection of specific columns from the
sandwiches_modeltable. The added columns include blockchain, project, version, block_time, block_month, block_number, token_sold_address, token_bought_address and so on. Additionally, a condition is added to filter rows whereblock_timeis greater than or equal to 7 days ago if it's an incremental update.MODEL: dex_info.sql
🟠 Modified by:
🔧 PR: #4455,
dex.info&nft.marketplaces_infocolumn fix🧙 Author: @hildobby on 2023-10-03
📝 Summary: In the given SQL model, the main logic that was added is a change in column names in the SELECT statement. The column 'codename' was replaced with 'project'. Additionally, there were changes made to the VALUES section where empty values for columns like name, marketplace_type, and x_username were removed.
MODEL: dex_trades.sql
🟠 Modified by:
🔧 PR: #4393, 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.
SECTOR: nft
toggle to see all model updates
MODEL: nft_ethereum_aggregators_manual.sql
🟠 Modified by:
🔧 PR: #4453, Update AlphaSharks name to Magically
🧙 Author: @GarvMaggu on 2023-10-05
📝 Summary: The logic that was added in this SQL model is the inclusion of new addresses and their corresponding names. Specifically, the addresses for 'Magically' were added with different versions (Alpha Sharks, Alpha Sharks 2.0, Alpha Sharks 2.1). Additionally, the address for 'LooksRare' Aggregator was also included. The logic that was removed includes multiple entries for 'Alpha Sharks'.
MODEL: nft_ethereum_aggregators_manual_legacy.sql
🟠 Modified by:
🔧 PR: #4453, Update AlphaSharks name to Magically
🧙 Author: @GarvMaggu on 2023-10-05
📝 Summary: In this SQL model, several addresses and their corresponding names were added or removed. The addresses and names for 'Alpha Sharks' were removed, while the same addresses were added with the name 'Magically'. Additionally, some Uniswap Universal Router addresses were added.
MODEL: nft_ethereum_aggregators_markers.sql
🟠 Modified by:
🔧 PR: #4453, Update AlphaSharks name to Magically
🧙 Author: @GarvMaggu on 2023-10-05
📝 Summary: The main logic added in this SQL model is a new condition in the CASE statement. If the value of
router_websiteis 'magically.gg', then set the aggregator name as 'Magically'. Additionally, there was a change where ifrouter_websitewas previously 'alphasharks.io', it would set the aggregator name as 'Alpha Sharks', but now it sets it as 'Magically'.MODEL: nft_ethereum_aggregators_markers_legacy.sql
🟠 Modified by:
🔧 PR: #4453, Update AlphaSharks name to Magically
🧙 Author: @GarvMaggu on 2023-10-05
📝 Summary: In this SQL model, the logic for mapping router_website values to aggregator_name has been modified. The condition for 'alphasharks.io' now maps to 'Magically', and a new condition has been added to map 'magically.gg' to 'Magically'. The rest of the code remains unchanged.
MODEL: nft_marketplaces_info.sql
🟠 Modified by:
🔧 PR: #4455, Update AlphaSharks name to Magically
🧙 Author: @GarvMaggu on 2023-10-05
📝 Summary: The model added a new row to the VALUES clause, with the values 'magically', 'Magically', 'Aggregator', and 'Magically_gg'. The row that was removed had the values 'alpha sharks', 'Alpha Sharks', and so on.
🔧 PR: #4455,
dex.info&nft.marketplaces_infocolumn fix🧙 Author: @hildobby on 2023-10-03
📝 Summary: In the given SQL model, the main logic that was added is a change in column names in the SELECT statement. The column 'codename' was replaced with 'project'. Additionally, there were changes made to the VALUES section where new rows were added for projects like 'stealcam', 'collectionswap', and 'decentraland'.
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 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 define the predicate for incremental updates.
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 directly queries from the 'nft_mints' table with similar conditions.
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 block_time greater than or equal to a specific date. 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.
SECTOR: labels
toggle to see all model updates
MODEL: labels_addresses.sql
🟠 Modified by:
🔧 PR: #3809,
labelsremove airdrop until upload source is fixed🧙 Author: @jeff-dude on 2023-10-05
📝 Summary: The reference model 'labels_airdrop' was removed.
🔧 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_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,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 usessource('dune_upload', 'op_airdrop1_addresses_detailed_list'). Additionally, there was a change in how the timestamp is defined, fromtimestamp('2022-09-29')toTIMESTAMP '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 table that includes information about addresses receiving an airdrop in the blockchain. It provides details such as the address, name of the receiver, category of the airdrop, contributor's name, source query used to fetch data, creation and update timestamps. The model is named 'op_airdrop_3_receivers' and uses 'persona' as its label type.
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 is not provided. Please provide the diff so that I can summarize it for you.
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. The comment suggests that it was disabled temporarily because balances were not working properly.
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 dynamic references. The list of error contracts has been updated with specific addresses instead of using a VALUES statement. Some string values have been changed from double quotes to single quotes. The created_at timestamp has been modified to use the TIMESTAMP function instead of a string value. Overall, these changes are related to data retrieval and formatting in order to populate an 'arbitrage_traders' table with relevant information from Ethereum transactions involving arbitrage traders.
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 constant values are also assigned to certain columns, such as category, contributor, source, created_at, updated_at. Additionally, some column names are changed from double quotes to single quotes.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 that was added includes:
timestampkeyword instead of a function call to set the value ofcreated_at.updated_atwith the current timestamp.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.
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_solana_fungible.sql
🟠 Modified by:
🔧 PR: #4476, Solana dex.trades (Lifinity v1/v2, Raydium v3, Phoenix v1, orca)
🧙 Author: @andrewhong5297 on 2023-10-05
📝 Summary: The added token symbols are: name, symbol
🔧 PR: #4476, automate fungible token metadata for solana
🧙 Author: @andrewhong5297 on 2023-10-03
📝 Summary: [changes too large] The model tokens_solana_fungible.sql was modified.
MODEL: tokens_solana_nft.sql
🟢 Added by:
🔧 PR: #4458, Solana nfts
🧙 Author: @andrewhong5297 on 2023-10-05
📝 Summary: This SQL model creates a view called 'token_metadata' that combines data from multiple sources to provide information about token metadata. It includes details such as the account mint authority, master edition, metadata, mint, version, token standard, name symbol and URI of the tokens. It also includes information about sellers' fee basis points and creators. The model enables data analysts to query this view to analyze and gain insights into token metadata updates over time. Additionally, it creates another view called 'cnfts' that provides information specifically for cNFTs (collateralized NFTs).
MODEL: tokens_solana_nft_legacy.sql
🟢 Added by:
🔧 PR: #4458, Solana nfts
🧙 Author: @andrewhong5297 on 2023-10-05
📝 Summary: This SQL model creates a dummy table with a single column that contains the value 1. It is likely used as a placeholder or temporary table for testing purposes and will be removed in the near future.
MODEL: tokens_arbitrum_erc20.sql
🟠 Modified by:
🔧 PR: #4385, Update tokens_arbitrum_erc20.sql
🧙 Author: @hmmdeif on 2023-10-04
📝 Summary: The token symbols that were added or removed in the diff are: Added: GRAI, DUSD, frxETH, oLIT, RDNT, FPI, svUSD,
SVY,
ABI,
OX,
WFIRE,
ACX
MODEL: tokens_ethereum_erc20.sql
🟠 Modified by:
🔧 PR: #4400, [Easy] Add more erc20 missing tokens
🧙 Author: @harisang on 2023-10-03
📝 Summary: [changes too large] The model tokens_ethereum_erc20.sql was modified.
MODEL: tokens_ethereum_erc20_legacy.sql
🟠 Modified by:
🔧 PR: #4400, [Easy] Add more erc20 missing tokens
🧙 Author: @harisang on 2023-10-03
📝 Summary: [changes too large] The model tokens_ethereum_erc20_legacy.sql was modified.
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 made 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.
SECTOR: prices
toggle to see all model updates
MODEL: prices_arbitrum_tokens.sql
🟠 Modified by:
🔧 PR: #4454, Update prices_arbitrum_tokens.sql
🧙 Author: @kvtoraman on 2023-10-04
📝 Summary: The token symbols that were added or removed are: USDC.e, USDC
MODEL: prices_polygon_tokens.sql
🟠 Modified by:
🔧 PR: #4434, Add gotchiverse tokens
🧙 Author: @ShaunGRAHAM on 2023-10-04
📝 Summary: The token symbols that were added are FUD, FOMO, and ALPHA.
SECTOR: test
toggle to see all model updates
MODEL: trigger_scale.sql
🟢 Added by:
🔧 PR: #4505, Use different trino cluster
🧙 Author: @belen-pruvost on 2023-10-06
📝 Summary: This SQL model creates a simple query that selects the value 1 and aliases it as 'test'. It enables data analysts to test the functionality of their SQL queries.
🟠 Modified by:
🔧 PR: #4505, new CI cluster setup: add is_legacy in alias macro
🧙 Author: @jeff-dude on 2023-10-06
📝 Summary: A dummy model was added to the SQL code. It is intended for use in GitHub Actions for pull request CI tests. The goal of this model is to run continuously until the cluster is spun up, as running a model helps turn the cluster back on after auto-shutdown. The SELECT statement returns 1 as 'test'.
MODEL: trigger_scale_legacy.sql
🟢 Added by:
🔧 PR: #4505, Use different trino cluster
🧙 Author: @belen-pruvost on 2023-10-06
📝 Summary: This SQL model creates a simple query that selects the value 1 and aliases it as 'test'. It enables data analysts to test the functionality of their SQL queries.
SECTOR: tigris
toggle to see all model updates
MODEL: tigris_arbitrum_events_add_margin.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In this SQL model, two sections were added: 'add_margin_events' and 'add_margin_calls'. In the 'add_margin_events' section, the logic was modified to only include data where
ap.evt_block_timeis greater than or equal to 7 days ago. This condition was changed to always be false (WHERE 1 = 0) in the merged pull request. Similarly, in the 'add_margin_calls' section, the logic for filtering data based onap.call_block_timewas also changed to always be false (WHERE 1 = 0).MODEL: tigris_arbitrum_events_close_position.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic added in this diff is a condition that sets the WHERE clause to '1 = 0' when the model is being run incrementally. This effectively filters out all rows from the source table, ensuring no data is selected for incremental runs.
MODEL: tigris_arbitrum_events_fees_distributed.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic added in this diff is a condition that filters the data based on the
evt_block_timecolumn. In the original model, it filtered for events within the last 7 days usingdate_trunc('day', now() - interval '7' day). However, in this pull request, that condition was changed toWHERE 1 = 0, effectively removing all data from being included in the model.MODEL: tigris_arbitrum_events_limit_cancel.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic added in this diff is a condition that sets the WHERE clause to '1 = 0' when the model is being run incrementally. This effectively filters out all rows from the source table, resulting in an empty result set.
MODEL: tigris_arbitrum_events_limit_order.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic that was added in this diff is a condition in the WHERE clause of the
limit_orders_v1model. The conditionWHERE 1 = 0ensures that no rows are returned when the model is run incrementally. This means that for incremental runs, no data will be selected from this model.MODEL: tigris_arbitrum_events_liquidate_position.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic added in this diff is a condition that sets the WHERE clause to '1 = 0' when the model is run incrementally. This effectively filters out all rows from the source table, preventing any data from being selected for incremental runs.
MODEL: tigris_arbitrum_events_modify_margin.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In this SQL model, the logic for filtering rows based on a specific time range has been modified. Previously, it used the
evt_block_timeorcall_block_timecolumns to filter rows within the last 7 days. However, in this diff, those conditions have been replaced with a condition that always evaluates to false (WHERE 1 = 0). This effectively removes any filtering based on time range from these models.MODEL: tigris_arbitrum_events_open_position.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic added in this diff is a condition that filters the
open_position_v1model based on the value ofis_incremental(). If it returns true, the model will only include rows wheret.evt_block_timeis greater than or equal to 7 days ago. Otherwise, if it returns false or null, no rows will be included in the model.MODEL: tigris_polygon_events_add_margin.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In this SQL model, two sections were modified. In the 'add_margin_events' section, a condition was added to filter out rows where 'ap.evt_block_time' is greater than or equal to 7 days ago. In the 'add_margin_calls' section, a similar condition was added to filter out rows where 'ap.call_block_time' is greater than or equal to 7 days ago.
MODEL: tigris_polygon_events_close_position.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In the given SQL model, two sections named 'close_position_v1_1' and 'close_position_v1_2' were modified. The logic that was added in both sections is a condition that sets the WHERE clause to 1 = 0, effectively filtering out all rows from the source table. This change seems to be related to incremental processing as it checks if it's an incremental run before applying this filter.
MODEL: tigris_polygon_events_fees_distributed.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic added in this diff is a condition that filters the data based on the
evt_block_timecolumn. In the original model, it filtered for events within the last 7 days usingdate_trunc('day', now() - interval '7' day). However, in this pull request, that condition was changed toWHERE 1 = 0, effectively removing all data from being included in the model.MODEL: tigris_polygon_events_limit_cancel.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In the given SQL model, the logic for filtering data based on
evt_block_timehas been removed. Previously, it was checking ift.evt_block_timeis greater than or equal to 7 days ago usingdate_trunc('day', now() - interval '7' day). Now, this condition has been replaced with a constant value of 0 usingWHERE 1 = 0. This change effectively disables the filtering based on block time.MODEL: tigris_polygon_events_limit_order.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: The main logic that was added in this diff is a condition in the WHERE clause of the SQL model. The condition '1 = 0' ensures that no rows are returned when the model is run incrementally. This means that for incremental runs, there will be no data selected from this table.
MODEL: tigris_polygon_events_liquidate_position.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In this SQL model, two sections were added and one section was removed. The added sections are 'liquidate_position_v1_1' and 'liquidate_position_v1_2'. Both sections select specific columns from the source table 'tigristrade_polygon' with the condition that evt_block_time is greater than or equal to a specific date. The removed section is a WHERE clause that filtered rows based on evt_block_time being within the last 7 days. It has been replaced with a condition that will always evaluate to false (WHERE 1 = 0).
MODEL: tigris_polygon_events_modify_margin.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In this SQL model, the logic for filtering data based on block time has been modified. Previously, it filtered data where the block time was within the last 7 days. Now, it filters out all data by setting a condition of 'WHERE 1 = 0', effectively excluding all rows from being selected. This change applies to three different sections: modify_margin_events_v1, add_margin_calls_v1, and remove_margin_calls_v1.
MODEL: tigris_polygon_events_open_position.sql
🟠 Modified by:
🔧 PR: #4430, Clean up tigris models
🧙 Author: @henrystats on 2023-10-06
📝 Summary: In this SQL model, the logic for filtering data based on a specific condition has been changed. The previous logic was to filter rows where the
evt_block_timecolumn is greater than or equal to 7 days ago. This has been replaced with a new condition that always evaluates to false (1 = 0). This means that no rows will be returned by this filter.MODEL: tigris_trades.sql
🟠 Modified by:
🔧 PR: #4479, Fix tigris pnl schema - ready for review - easy
🧙 Author: @henrystats on 2023-10-04
📝 Summary: The main logic that was removed in this diff is the closing of a subquery.
MODEL: tigris_trades_pnl.sql
🟢 Added by:
🔧 PR: #4375, add tigris trades pnl - ready for review
🧙 Author: @henrystats on 2023-09-29
📝 Summary: This SQL model creates a view that combines data from multiple tables related to margin positions, closing positions, and liquidating positions. It calculates the profit and loss (pnl) for each position based on the payout and percentage closed. The view also includes information about wins and losses for each position. This model enables data analysts to analyze pnl, wins, losses, and other metrics related to closing or liquidating positions in different blockchains.
🟠 Modified by:
🔧 PR: #4375, Fix tigris pnl schema - ready for review - easy
🧙 Author: @henrystats on 2023-10-04
📝 Summary: The logic added in this diff is a calculation of wins and losses based on the pnl (profit and loss) value. If the pnl is greater than 0, it is considered a win (1), otherwise it's considered a loss (0). The model also includes a left join to match records from another table using evt_tx_hash and blockchain columns. Additionally, there is an instruction to select all rows from close_liquidate_pnl for reloading purposes.
MODEL: tigris_trades_pnl_legacy.sql
🟢 Added by:
🔧 PR: #4375, add tigris trades pnl - ready for review
🧙 Author: @henrystats on 2023-09-29
📝 Summary: This SQL model creates a simple SELECT statement that selects the value 1. It enables data analysts to retrieve and work with this specific value in their queries or calculations.
SECTOR: arrakis
toggle to see all model updates
MODEL: arrakis_uniswap_pools.sql
🟠 Modified by:
🔧 PR: #4515, SPE-145 Misc models migration
🧙 Author: @couralex6 on 2023-10-06
📝 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: arrakis_optimism_uniswap_pools.sql
🟠 Modified by:
🔧 PR: #4515, SPE-145 Misc models migration
🧙 Author: @couralex6 on 2023-10-06
📝 Summary: The main logic added in this SQL model is the conversion of token0 and token1 columns to varchar using the CAST function. Additionally, a condition was added to filter rows where evt_block_time is greater than or equal to one month ago. The blockchain column is selected as 'optimism' and a concatenation operation is performed on symbol values, separated by '/', '-', and '%'.
SECTOR: balances
toggle to see all model updates
MODEL: genesis_balances.sql
🟠 Modified by:
🔧 PR: #4515, SPE-145 Misc models migration
🧙 Author: @couralex6 on 2023-10-06
📝 Summary: [changes too large] The model genesis_balances.sql was modified.
SECTOR: bridge
toggle to see all model updates
MODEL: optimism_standard_bridge_flows.sql
🟠 Modified by:
🔧 PR: #4515, SPE-145 Misc models migration
🧙 Author: @couralex6 on 2023-10-06
📝 Summary: In this SQL model, a left join is added to connect the 'chain_info_chain_ids' table with the 'tf' table using the column 'destination_chain_id'. This allows for retrieving information from both tables based on matching chain IDs.
SECTOR: hop_protocol
toggle to see a
Beta Was this translation helpful? Give feedback.
All reactions