Feature/rejected txs index #1846
Conversation
| @@ -39,6 +39,15 @@ namespace { | |||
| return (base % hash.hex() % height).str(); | |||
| } | |||
|
|
|||
| std::string makeRejectedTxHashIndex( | |||
There was a problem hiding this comment.
I suggest a bit different naming - storeRejectedTxHash
Otherwise make index sounds like CREATE INDEX index_name ON table_name (column1, column2, ...); will be executed under the hood :)
There was a problem hiding this comment.
I agree with you. My intention was to keep the naming consisted with other methods here. I can add the task to provide better naming for that function
| const shared_model::crypto::Hash &hash) { | ||
| return getBlockId(hash) != boost::none; | ||
| } | ||
|
|
||
| bool PostgresBlockQuery::hasRejectedTxWithHash( |
There was a problem hiding this comment.
Why should we separate hashes storage on two methods?
Why could we not store both kinds of hashes in the same table with different markers in a separate column?
something like:
+-----+----------------+--------------------+-----+
| ... | hash | committed/rejected | ... |
+-----+----------------+--------------------+-----+
| | 2ac7b67ca6b76c | committed | |
+-----+----------------+--------------------+-----+
| | 89ac7b867a875a | rejected | |
+-----+----------------+--------------------+-----+
That approach will let us avoid looking up in two independent sources for the single transaction in the worst case.
Also, we will have only one method for a transaction look up.
There was a problem hiding this comment.
Looks good to me but please consider possibility of @igor-egorov suggestion about using a single table.
Signed-off-by: kamilsa <[email protected]>
Signed-off-by: kamilsa <[email protected]>
Signed-off-by: kamilsa <[email protected]>
Signed-off-by: kamilsa <[email protected]>
Signed-off-by: kamilsa <[email protected]>
kamilsa
force-pushed
the
feature/rejected_txs_index
branch
from
be3fcb4 to
39875f1
Compare
Signed-off-by: kamilsa <[email protected]>
Signed-off-by: kamilsa <[email protected]>
| @@ -508,6 +508,12 @@ CREATE TABLE IF NOT EXISTS height_by_hash ( | |||
| hash varchar, | |||
| height text | |||
| ); | |||
|
|
|||
| CREATE TABLE IF NOT EXISTS height_by_rejected_hash ( | |||
There was a problem hiding this comment.
Add drop table please (somewhere)
Description of the Change
We should be able to check whether transaction has been processed by ledger, even if it was rejected. This PR adds this functionality by adding hasRejectedTxWithHash query in block query. In future it can be used by committed transactions cache.
Benefits
Now we have all means to implement fair implementation of committed transactions cache
Possible Drawbacks
None
Usage Examples or Tests
Corresponding tests on block query were provided