Disk related functions should be seperated out from ClaimTrie class into its own class #136
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
hard fork
help wanted
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
soft fork
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbrycrd#136
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
All disk read/write functions done through the CDBWrapper class in ClaimTrie should be separated out onto its own file/class. This should improve readability as it should be much clearer what is being saved and how. We should also write unit tests for the separated out disk read/write class.
I will try to make the task. You mean CDBWrapper (reads from disk) as well as CDBBatch (write to disk) to separated in related class, right?
Yes basically anything that has to do with CClaimTrie.db in claimtrie.h/cpp
I found that architecture is not good enough to me. Did you accept more agressive refactor? Why, CClaimTrieCache should have all dirty nodes and CClaimTrie should search in, when it's not found, then query CClaimTrieDb (new separed class) so CClaimTrie became a interface between cache and db. This will result in remove of all dirtyQueueXXX and related functions from CClaimTrie. Is this acceptable to you?
https://github.com/lbryio/lbrycrd/pull/140
It's simple, i can make more aggressive refactor if still needs
handled by #175
closing for #175