You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
. My hope is that with the index the caller will then be able to copy that response directly from the shard that provided the "final" range that got merged. I'm up for ideas on this one. I think we need to ensure that the caller doesn't accidentally provide a larger global txo count than the number of blocks. Lets assume there are 3 txos per block and the ranges are (0,10), (10, 12), (20, 22). The intent is that our max block returned is 12, I'm thinking we also need to ensure the gobal_txo_count is 36 and not 66.
I don't think there is any use in providing a merged range that doesn't start at 0, for the system. However for this function I think it's already complicated enough with the index piece. My thought was that the caller would do something like (non compiling code)
let zero_range = BlockRange::new(0,1);let received_ranges = ranges.sort();// some logic somewhere that keeps the indices when sorted.let(index, merged_range) = BlockRange.merge_from_ranges([&zero_range].chain(received_ranges));
Up for suggestions as I recognize this may be placing too much room for error by the callers
. My hope is that with the index the caller will then be able to copy that response directly from the shard that provided the "final" range that got merged. I'm up for ideas on this one. I think we need to ensure that the caller doesn't accidentally provide a larger global txo count than the number of blocks. Lets assume there are 3 txos per block and the ranges are (0,10), (10, 12), (20, 22). The intent is that our max block returned is 12, I'm thinking we also need to ensure the gobal_txo_count is 36 and not 66.
I don't think there is any use in providing a merged range that doesn't start at 0, for the system. However for this function I think it's already complicated enough with the index piece. My thought was that the caller would do something like (non compiling code)
let zero_range = BlockRange::new(0,1);let received_ranges = ranges.sort();// some logic somewhere that keeps the indices when sorted.let(index, merged_range) = BlockRange.merge_from_ranges([&zero_range].chain(received_ranges));
Up for suggestions as I recognize this may be placing too much room for error by the callers
Ah. Fessing up to initiating the internal conversation, and this makes sense to me.
Up for suggestions as I recognize this may be placing too much room for error by the callers
What if each BlockRange included the query_response from the corresponding shard? Then instead of doing a merge_from_range, do abest_query_response where all of the shard query_responses are sorted by start_block and looked at in order until a discontinuity is found (or the end of the sorted BlockRange list is reached) and the query_response from before the discontinuity (or final one in list if there is no discontinuity) is returned?
Then num_blocks, global_txo_count, and latest_block_version could be taken from that query_response.
Some logic would also be needed in case none of the shards reported results that included block 0.
Up for suggestions as I recognize this may be placing too much room for error by the callers
What if each BlockRange included the query_response from the corresponding shard? Then instead of doing a merge_from_range, do abest_query_response where all of the shard query_responses are sorted by start_block and looked at in order until a discontinuity is found (or the end of the sorted BlockRange list is reached) and the query_response from before the discontinuity (or final one in list if there is no discontinuity) is returned?
Then num_blocks, global_txo_count, and latest_block_version could be taken from that query_response.
Some logic would also be needed in case none of the shards reported results that included block 0.
This may be a better alternative. The shards are going to need to return a different type then the CheckKeyImagesResponse in order to accomodate the range. So it may make sense to create a dedicated NewResponseType::merge_from(responses) and contain the logic there.
I'll keep this PR open/unmerged for now and build the other logic on top of this to see how it plays out.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.