refactor(common): remove storage_commitment and class_commitment from BlockHeader
#2452
Conversation
57858cc to
437da05
Compare
BlockHeaderstorage_commitment and class_commitment from BlockHeader
- Remove `storage_commitment` and `class_commitment` fields from `BlockHeader` - Remove `storage_commitment` and `class_commitment` fields from: a) `pathfinder_getProof` b) `pathfinder_subscribe_newHeads` - Drop `storage_commitment` and `class_commitment` columns in block_headers table
437da05 to
b07d337
Compare
| tx.execute_batch( | ||
| r" | ||
| ALTER TABLE block_headers DROP COLUMN storage_commitment; | ||
| ALTER TABLE block_headers DROP COLUMN class_commitment; | ||
| ", | ||
| ) | ||
| .context("Removing storage_commitment and class_commitment columns from block_headers table") |
There was a problem hiding this comment.
BTW: I wonder how long this takes on a mainnet DB.
There was a problem hiding this comment.
2 seconds. From the SQLite docs:
SQLite stores the schema as plain text in the sqlite_schema table. The DROP COLUMN command (and all of the other variations of ALTER TABLE as well) modify that text and then attempt to reparse the entire schema. The command is only successful if the schema is still valid after the text has been modified. In the case of the DROP COLUMN command, the only text modified is that the column definition is removed from the CREATE TABLE statement. The DROP COLUMN command will fail if there are any traces of the column in other parts of the schema that will prevent the schema from parsing after the CREATE TABLE statement has been modified.
IIRC DROP COLUMN does not free any space, but marks space as unused so it can be used by other data. We may or may not want to do a vacuum after the DROP COLUMN. I personally don't think we need it; I doubt that storage savings from these two columns would be huge anyway, and with a vacuum this migration would take much longer than 2 seconds.
Closes #2411.