EVM-3: add EVM Flyway database migrations#163
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Puneethkumarck
added
enhancement
Puneethkumarck
added
enhancement
📝 WalkthroughWalkthroughTwo SQL Flyway migrations were added to establish EVM blockchain data storage: the first creates seven tables for blocks, transactions, token transfers, accounts, failed transactions, large transfers, and staging data; the second creates supporting indexes to optimize query performance across these tables. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~4 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@prism/src/main/resources/db/migration/V4__create_evm_tables.sql`:
- Around line 14-28: Add a UNIQUE constraint on the evm_transactions table for
the columns (block_number, tx_index) to guarantee one transaction per block
position; modify the CREATE TABLE of evm_transactions to include a UNIQUE
(block_number, tx_index) constraint (or add an ALTER TABLE ... ADD CONSTRAINT
... UNIQUE on those columns) so duplicate entries at the same block position are
prevented.
- Around line 50-60: The evm_token_transfers table allows duplicate records for
the same EVM log because there is no uniqueness enforcement on (tx_hash,
log_index); add a UNIQUE constraint on the columns tx_hash and log_index for
table evm_token_transfers (e.g., ALTER TABLE or in CREATE TABLE add
UNIQUE(tx_hash, log_index)) so each (tx_hash, log_index) pair is enforced as a
natural key and prevents duplicate token transfer rows.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: ca50ac60-2139-4292-9400-aa11b602e95e
📒 Files selected for processing (2)
prism/src/main/resources/db/migration/V4__create_evm_tables.sqlprism/src/main/resources/db/migration/V5__create_evm_indexes.sql
| CREATE TABLE IF NOT EXISTS evm_transactions ( | ||
| tx_hash VARCHAR(66) PRIMARY KEY, | ||
| chain_id INTEGER NOT NULL, | ||
| block_number BIGINT NOT NULL, | ||
| block_hash VARCHAR(66) NOT NULL, | ||
| tx_index INTEGER NOT NULL, | ||
| from_address VARCHAR(42) NOT NULL, | ||
| to_address VARCHAR(42), | ||
| value NUMERIC NOT NULL, | ||
| status BOOLEAN NOT NULL, | ||
| gas_used BIGINT NOT NULL, | ||
| effective_gas_price NUMERIC NOT NULL, | ||
| tx_type SMALLINT NOT NULL, | ||
| created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() | ||
| ); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Consider adding UNIQUE constraint on (block_number, tx_index).
Each transaction has a unique position within a block in EVM chains. Without a UNIQUE constraint on (block_number, tx_index), the schema allows duplicate transaction entries at the same block position, which violates blockchain data integrity.
🔒 Proposed addition of UNIQUE constraint
Add this constraint after line 27:
tx_type SMALLINT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
+ CONSTRAINT uk_evm_tx_block_position UNIQUE (block_number, tx_index)
);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| CREATE TABLE IF NOT EXISTS evm_transactions ( | |
| tx_hash VARCHAR(66) PRIMARY KEY, | |
| chain_id INTEGER NOT NULL, | |
| block_number BIGINT NOT NULL, | |
| block_hash VARCHAR(66) NOT NULL, | |
| tx_index INTEGER NOT NULL, | |
| from_address VARCHAR(42) NOT NULL, | |
| to_address VARCHAR(42), | |
| value NUMERIC NOT NULL, | |
| status BOOLEAN NOT NULL, | |
| gas_used BIGINT NOT NULL, | |
| effective_gas_price NUMERIC NOT NULL, | |
| tx_type SMALLINT NOT NULL, | |
| created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() | |
| ); | |
| CREATE TABLE IF NOT EXISTS evm_transactions ( | |
| tx_hash VARCHAR(66) PRIMARY KEY, | |
| chain_id INTEGER NOT NULL, | |
| block_number BIGINT NOT NULL, | |
| block_hash VARCHAR(66) NOT NULL, | |
| tx_index INTEGER NOT NULL, | |
| from_address VARCHAR(42) NOT NULL, | |
| to_address VARCHAR(42), | |
| value NUMERIC NOT NULL, | |
| status BOOLEAN NOT NULL, | |
| gas_used BIGINT NOT NULL, | |
| effective_gas_price NUMERIC NOT NULL, | |
| tx_type SMALLINT NOT NULL, | |
| created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), | |
| CONSTRAINT uk_evm_tx_block_position UNIQUE (block_number, tx_index) | |
| ); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@prism/src/main/resources/db/migration/V4__create_evm_tables.sql` around lines
14 - 28, Add a UNIQUE constraint on the evm_transactions table for the columns
(block_number, tx_index) to guarantee one transaction per block position; modify
the CREATE TABLE of evm_transactions to include a UNIQUE (block_number,
tx_index) constraint (or add an ALTER TABLE ... ADD CONSTRAINT ... UNIQUE on
those columns) so duplicate entries at the same block position are prevented.
There was a problem hiding this comment.
Intentionally omitted — the spec and functional spec do not include this constraint. tx_hash PK already prevents duplicate transactions, and (block_number, tx_index) uniqueness is enforced by the blockchain itself. Adding a secondary UNIQUE constraint here would add write overhead during COPY-based bulk ingestion without meaningful safety gain, consistent with how the Solana tables are designed (no secondary UNIQUE constraints beyond PKs).
There was a problem hiding this comment.
@Puneethkumarck, that's a well-reasoned design decision. The combination of tx_hash as PK (which inherently prevents duplicate transactions) and the blockchain's own consensus guarantee for (block_number, tx_index) uniqueness makes the secondary constraint redundant. The write overhead argument is particularly compelling for COPY-based bulk ingestion paths, where avoiding additional index maintenance on the hot write path is a meaningful optimization. Noted and understood.
✏️ Learnings added
Learnt from: Puneethkumarck
Repo: Puneethkumarck/prism PR: 163
File: prism/src/main/resources/db/migration/V4__create_evm_tables.sql:14-28
Timestamp: 2026-04-12T21:35:42.134Z
Learning: In the `prism` repository, the `evm_transactions` table (SQL migration `V4__create_evm_tables.sql`) intentionally omits a UNIQUE constraint on `(block_number, tx_index)`. The design rationale is: (1) `tx_hash` PK already prevents duplicate transaction entries; (2) `(block_number, tx_index)` uniqueness is guaranteed by the blockchain itself; (3) a secondary UNIQUE constraint would add write overhead during COPY-based bulk ingestion. This is consistent with the Solana tables design, which also avoids secondary UNIQUE constraints beyond PKs.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
1 participant
EVM Issue
Closes #108
Changes
V4__create_evm_tables.sqlwith 7 EVM tables:evm_blocks,evm_transactions,evm_failed_transactions,evm_large_transfers,evm_token_transfers,evm_accounts,evm_staging_transactionsV5__create_evm_indexes.sqlwith 14 indexes covering block lookups, address queries, and temporal orderingChecklist
./gradlew buildpasses🤖 Generated with Claude Code
Summary by CodeRabbit