Storage: remove get_range
#359
Conversation
| let (block_ids, block_weights) = (first_known_height..last_height_in_chain_entry) | ||
| .into_iter() | ||
| .map(|height| { | ||
| let block_info = table_block_infos.get(&height)?; |
There was a problem hiding this comment.
That is a temporary fix right?
github-actions
bot
added
A-dependency
|
@hinto-janai I spent way too much time trying to get this to work without success, for now I think this is the best option. If you have an idea, feel free, although I don't think it's worth spending much time on when it's not used much. |
| name = "redb" | ||
| version = "2.2.0" | ||
| version = "2.3.0" | ||
| source = "registry+https://github.com/rust-lang/crates.io-index" | ||
| checksum = "84b1de48a7cf7ba193e81e078d17ee2b786236eed1d3f7c60f8a09545efc4925" | ||
| checksum = "a7c2a94325f9c5826b17c42af11067230f503747f870117a28180e85696e21ba" |
There was a problem hiding this comment.
#212 can be closed when this is merged.
| /* | ||
| FIXME: <https://github.com/Cuprate/cuprate/issues/348> |
There was a problem hiding this comment.
Would it be worth leaving this as-is then where used in cuprate_blockchain it branches on the backend? E.g.:
let tx_blobs = if cfg!(feature = "heed") {
(first_tx_idx..(usize_to_u64(numb_non_miner_txs) + first_tx_idx))
.map(|idx| {
let tx_blob = tables.tx_blobs().get(&idx)?.0;
Ok(Bytes::from(tx_blob))
})
.collect::<Result<_, RuntimeError>>()?
} else {
tables
.tx_blobs_iter()
.get_range(first_tx_idx..(usize_to_u64(numb_non_miner_txs) + first_tx_idx))?
.map(|tx_blob| Ok(Bytes::from(tx_blob?.0)))
.collect::<Result<_, RuntimeError>>()?
};Or is it not that important for now?
There was a problem hiding this comment.
Or actually, the DatabaseIter::get_range impl for heed would just use get internally.
There was a problem hiding this comment.
Or actually, the DatabaseIter::get_range impl for heed would just use get internally.
I tried to do this but it's harder than it sounds. In get_range we don't know how much of the range we actually have, i.e if we ask for 0..100 but we only have the key 50 stored we still need to check the other 99 keys, not impossible but defiantly a footgun IMO.
Would it be worth leaving this as-is then where used in cuprate_blockchain it branches on the backend?
I don't think the complexity is worth it. This is only used for other nodes syncing from us, which from some initial tests, is still significantly faster than monerod
#348