-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
katana: simplify database backend by removing in-memory provider #2571
Changes from all commits
63d0330
59c6dcf
81b6fa7
a3bdf5e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,7 +18,7 @@ fn executor_transact(c: &mut Criterion) { | |
let mut group = c.benchmark_group("Invoke.ERC20.transfer"); | ||
group.warm_up_time(Duration::from_millis(200)); | ||
|
||
let provider = test_utils::test_in_memory_provider(); | ||
let provider = test_utils::test_provider(); | ||
let flags = SimulationFlag::new(); | ||
Comment on lines
+21
to
22
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion Consider adding warm cache benchmarks Since we're now using a database backend, it would be valuable to benchmark both cold and warm cache scenarios to understand the performance characteristics better. Consider adding a warm cache variant like this: let provider = test_utils::test_provider();
let flags = SimulationFlag::new();
+
+// Add warm cache benchmark
+let warm_provider = provider.clone();
+// Pre-warm the cache by executing a dummy transaction
+blockifier(&mut group, &warm_provider, &flags, &envs, tx.clone());
|
||
|
||
let tx = tx(); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -239,7 +239,7 @@ mod tests { | |
}; | ||
use katana_primitives::utils::class::{parse_compiled_class, parse_sierra_class}; | ||
use katana_primitives::{address, Felt}; | ||
use katana_provider::providers::in_memory::InMemoryProvider; | ||
use katana_provider::providers::db::DbProvider; | ||
use katana_provider::traits::contract::ContractClassWriter; | ||
use katana_provider::traits::state::{StateFactoryProvider, StateProvider, StateWriter}; | ||
use starknet::macros::felt; | ||
|
@@ -267,7 +267,7 @@ mod tests { | |
let legacy_class_hash = felt!("0x111"); | ||
let legacy_class = DEFAULT_LEGACY_ERC20_CASM.clone(); | ||
|
||
let provider = InMemoryProvider::new(); | ||
let provider = katana_provider::test_utils::test_provider(); | ||
provider.set_nonce(address, nonce).unwrap(); | ||
provider.set_class_hash_of_contract(address, class_hash).unwrap(); | ||
provider.set_storage(address, storage_key, storage_value).unwrap(); | ||
|
@@ -452,7 +452,7 @@ mod tests { | |
|
||
#[test] | ||
fn fetch_non_existant_data() -> anyhow::Result<()> { | ||
let db = InMemoryProvider::new(); | ||
let db = DbProvider::new_ephemeral(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 Codebase verification Ohayo sensei! After analyzing the codebase, I can now provide a final response about the InMemoryProvider usage. The InMemoryProvider references need to be updated in test templates The test files still use InMemoryProvider in their template definitions, specifically in:
However, these templates are already being correctly applied with DbProvider in the actual test implementations. The InMemoryProvider is only referenced in the template definitions but not actually used in the running tests, as evidenced by the working test implementations using DbProvider. • 🔗 Analysis chainGood choice using ephemeral storage for tests, sensei! The switch to Let's verify that all test cases using InMemoryProvider have been updated: Let me gather more context about these test files to understand if they need to be updated. Let me check if there are any other files that might be using InMemoryProvider, particularly in the fixtures module that's being imported by these test files. 🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Search for any remaining instances of InMemoryProvider in test files
rg "InMemoryProvider" --type rust --type-add "rust:*.rs"
Length of output: 457 Script: #!/bin/bash
# Check the content of these test files to understand the context
echo "=== class.rs ==="
cat crates/katana/storage/provider/tests/class.rs
echo -e "\n=== contract.rs ==="
cat crates/katana/storage/provider/tests/contract.rs
echo -e "\n=== storage.rs ==="
cat crates/katana/storage/provider/tests/storage.rs
Length of output: 18575 Script: #!/bin/bash
# Check the fixtures module content
echo "=== fixtures.rs ==="
cat crates/katana/storage/provider/tests/fixtures.rs
Length of output: 7421 |
||
|
||
let address = address!("0x1"); | ||
let class_hash = felt!("0x123"); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -31,7 +31,6 @@ use katana_pool::ordering::FiFo; | |
use katana_pool::validation::stateful::TxValidator; | ||
use katana_pool::TxPool; | ||
use katana_primitives::env::{CfgEnv, FeeTokenAddressses}; | ||
use katana_provider::providers::in_memory::InMemoryProvider; | ||
use katana_rpc::dev::DevApi; | ||
use katana_rpc::metrics::RpcServerMetrics; | ||
use katana_rpc::saya::SayaApi; | ||
|
@@ -187,7 +186,8 @@ pub async fn build(mut config: Config) -> Result<Node> { | |
let db = katana_db::init_db(db_path)?; | ||
(Blockchain::new_with_db(db.clone(), &config.chain)?, Some(db)) | ||
} else { | ||
(Blockchain::new_with_chain(InMemoryProvider::new(), &config.chain)?, None) | ||
let db = katana_db::init_ephemeral_db()?; | ||
(Blockchain::new_with_db(db.clone(), &config.chain)?, Some(db)) | ||
Comment on lines
+189
to
+190
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 Codebase verification Ohayo sensei! We need to clean up the remaining InMemoryProvider references! The verification revealed that while the main code has moved to using ephemeral DB, there are still test files using Points that need attention:
🔗 Analysis chainOhayo sensei! The database initialization change looks good! The replacement of the in-memory provider with an ephemeral database aligns perfectly with the PR's objective of simplifying the database backend. This change standardizes the database interaction pattern across the codebase. Let's verify that all in-memory provider references have been properly removed: The previous results show some references to InMemoryProvider in tests and imports from in_memory modules. Let's dig deeper to understand if these are legitimate remaining usages or if they need to be cleaned up as part of the in-memory provider removal. The previous results show the existence of in_memory related code and test references. Let's examine the actual content of these files to understand if they are part of the old implementation that needs to be removed or if they serve a different purpose. 🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Check for any remaining references to InMemoryProvider
# to ensure complete removal across the codebase
echo "Checking for InMemoryProvider references..."
rg "InMemoryProvider"
echo "Checking for in-memory related imports..."
rg "use.*in_memory"
echo "Checking for in-memory related test configurations..."
rg "in_memory.*provider"
Length of output: 1461 Script: #!/bin/bash
# Let's check for the actual InMemoryProvider implementation and its usage
# Check for InMemoryProvider struct/type definition
echo "=== Checking InMemoryProvider definition ==="
ast-grep --pattern 'struct InMemoryProvider'
# Check for InMemoryProvider imports in test files
echo -e "\n=== Checking InMemoryProvider imports in tests ==="
rg "use.*InMemoryProvider" -A 2
# Check for any remaining in-memory provider related code
echo -e "\n=== Checking in-memory provider module structure ==="
fd "in_memory" --type d
# Check content of in_memory related files
echo -e "\n=== Checking content of in_memory related files ==="
fd "in_memory" --type f --exec echo "=== {} ===" \; --exec head -n 5 {} \;
Length of output: 695 Script: #!/bin/bash
# Let's examine the specific files that still contain InMemoryProvider references
echo "=== Checking the content of test files with InMemoryProvider ==="
cat crates/katana/storage/provider/tests/storage.rs
echo -e "\n=== Checking the content of contract test ==="
cat crates/katana/storage/provider/tests/contract.rs
echo -e "\n=== Checking the content of class test ==="
cat crates/katana/storage/provider/tests/class.rs
echo -e "\n=== Checking the in_memory module content ==="
cat crates/katana/storage/provider/src/providers/in_memory/mod.rs
echo -e "\n=== Checking if InMemoryProvider is still exported in lib.rs ==="
rg "pub.*InMemoryProvider" crates/katana/storage/provider/src/lib.rs
Length of output: 19192 |
||
}; | ||
|
||
let block_context_generator = BlockContextGenerator::default().into(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Clean type conversion implementation, sensei!
The match statement properly handles the conversion between different
L1DataAvailabilityMode
types. However, we could make it more concise.Consider simplifying the match statement:
📝 Committable suggestion