perf(storage)!: merge tabels with tx index key

[DvirYo-starkware]

This change is 

[DvirYo-starkware]

Reviewable status: 0 of 8 files reviewed, 1 unresolved discussion (waiting on @dan-starkware and @ShahakShama)

---

crates/papyrus_rpc/src/v0_6/execution_test.rs line 765 at r1 (raw file):

            BlockBody {
                transactions: vec![tx1, tx2],
                transaction_outputs: vec![

without adding one more tx output, this test will now fail because the block has 2 tx but only one tx output.

[codecov]

Codecov Report

Attention: Patch coverage is 70.32967% with 27 lines in your changes are missing coverage. Please review.

Project coverage is 70.07%. Comparing base (9723746) to head (d542cdd).

Files	Patch %	Lines
crates/papyrus_storage/src/body/mod.rs	74.64%	0 Missing and 18 partials ⚠️
crates/papyrus_storage/src/body/events.rs	55.55%	0 Missing and 8 partials ⚠️
crates/papyrus_storage/src/lib.rs	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2022      +/-   ##
==========================================
- Coverage   70.09%   70.07%   -0.03%     
==========================================
  Files         131      131              
  Lines       17100    17083      -17     
  Branches    17100    17083      -17     
==========================================
- Hits        11987    11971      -16     
- Misses       3776     3786      +10     
+ Partials     1337     1326      -11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ShahakShama]

Reviewed 8 of 8 files at r1.
Reviewable status: 0 of 8 files reviewed, 1 unresolved discussion (waiting on @dan-starkware and @ShahakShama)

---

crates/papyrus_rpc/src/v0_6/execution_test.rs line 765 at r1 (raw file):

Previously, DvirYo-starkware wrote…

without adding one more tx output, this test will now fail because the block has 2 tx but only one tx output.

It might be good to add a test that this fails

---

crates/papyrus_storage/src/body/events.rs line 118 at r1 (raw file):

// TODO(dvir): add transaction hash to the return value. In the RPC when returning events this is
// with the transaction hash. We can do it efficiently here because we anyway read the relevant
// entry in the transaction_metadata table..

This also good for validations, since the event hash calculation depends on the transaction hash

---

crates/papyrus_storage/src/body/mod.rs line 278 at r1 (raw file):

        transaction_metadata_table: TransactionMetadataTable<'env>,
    ) -> StorageResult<Option<Vec<TransactionOutput>>> {
        if self.get_body_marker()? <= block_number {

There's code duplication with the functions below. Consider adding a utility function that receives a function that converts metadata to what you need
I did something similar in the RPC. You can TAL if you want

---

crates/papyrus_storage/src/body/mod.rs line 301 at r1 (raw file):

    }

    fn get_transactions_in_block(

For next time, if you move code around and make changes to it, split it into two commits to make it easier for the reviewer

[ShahakShama]

Reviewed 8 of 8 files at r1.
Reviewable status: 5 of 8 files reviewed, 2 unresolved discussions (waiting on @dan-starkware and @DvirYo-starkware)

[DvirYo-starkware]

Reviewable status: 4 of 8 files reviewed, 1 unresolved discussion (waiting on @dan-starkware and @ShahakShama)

---

crates/papyrus_rpc/src/v0_6/execution_test.rs line 765 at r1 (raw file):

Previously, ShahakShama wrote…

It might be good to add a test that this fails

I added todo for that.

---

crates/papyrus_storage/src/body/mod.rs line 278 at r1 (raw file):

Previously, ShahakShama wrote…

There's code duplication with the functions below. Consider adding a utility function that receives a function that converts metadata to what you need
I did something similar in the RPC. You can TAL if you want

Done.

[ShahakShama]

Reviewed 3 of 3 files at r2, 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @dan-starkware)