-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pool DB operation removePools
#2038
Conversation
b0eb33a
to
8461a48
Compare
8461a48
to
c36325b
Compare
ae765e8
to
6447bf7
Compare
6447bf7
to
8d5c7cb
Compare
lib/core/src/Cardano/DB/Sqlite.hs
Outdated
@@ -372,6 +372,7 @@ data DBLog | |||
| MsgWaitingForDatabase Text (Maybe Int) | |||
| MsgRemovingInUse Text Int | |||
| MsgRemoving Text | |||
| MsgRemovingDatabaseEntity Text |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about being more specific?
MsgRemovePool PoolId
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about being more specific?
MsgRemovePool PoolId
I do agree that we should use specific types, wherever possible, rather than Text
.
However, one issue is that DBLog
type is general to all databases. Ideally, DBLog
shouldn't use types that are specific to pools or wallets.
An obvious solution would be to introduce WalletDbLog
and PoolDbLog
types, of which the latter would have the constructor that you suggest: MsgRemovePool
.
However, this would require changing references to DBLog
in quite a few places. If we decide to do this, I suggest we create a separate PR (or make an item of technical debt), in order to avoid complicating this one too much.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created a technical debt ticket to cover the idea of defining separate WalletDbLog
and PoolDbLog
types here: https://jira.iohk.io/browse/ADP-407.
While tackling the above ticket, we could also go through the existing DbLog
constructors and replace the "stringly-typed" constructors with strongly-typed equivalents in WalletDbLog
and PoolDbLog
. Hopefully, this should also clean up parts of the code that are obscured with log formatting logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like this to be fixed now, rather than kicking the can down the road.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rvl wrote:
I would like this to be fixed now, rather than kicking the can down the road.
It wasn't clear to me that your original feedback wasn't just a suggestion:
How about being more specific?
MsgRemovePool PoolId
I agree that this would be better, but IMO fixing the lack of type specialization in DBLog
is really orthogonal to the purpose of this PR, whose main focus is the removal of pools from the database. That the log messages use Text
rather than PoolId
seems like a minor issue, and not really a valid reason to delay the whole PR. (The other constructors in this type also use Text
, so it's not inconsistent with the original code.)
IMO, it would be better to make these changes in separate PRs:
- PR A: Implement the
removePools
operation. - PR B: Divide
DBLog
intoPoolDbLog
andWalletDbLog
, and convert the various "stringly-typed" constructors withinDBLog
into strongly-typed constructors.
Indeed, we already had a ticket in place to perform the refactoring here https://jira.iohk.io/browse/ADP-407
But by attempting to do the refactoring in this PR, we risk adding extra delay, as any lack of consensus about how to perform the refactoring will end up delaying the PR as a whole.
Nevertheless, I've added the following commits:
- bcec1b9 (Provide database-schema-specific logging types.)
- 44a72ec (Introduce log constructor
MsgRemovingPool
.) - 8e5449f (Use
MsgRemovingPool
inremovePools
operation.) - b5f1579 (Remove unused
MsgRemovingDatabaseEntity
log constructor.)
Could have a look at these commits and let me know your thoughts?
Thanks!
8d5c7cb
to
b7636eb
Compare
b7636eb
to
6039042
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the logging changes - thanks for trying to fix it.
I would go with something simpler.
Create a PoolDBLog
data type which embeds DBLog plus your new log messages.
Then all the changes will be local to the Pool.DB.Sqlite
module, and we don't need a DBLog schema
type parameter everywhere.
In response to review feedback: #2038 (comment) #2038 (review)
bfcc8e8
to
cb87439
Compare
In response to review feedback: #2038 (comment) #2038 (review)
cb87439
to
70a3cfd
Compare
Thanks for this suggestion. I've changed the types as you suggest. See commits from 82be504 onwards. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
bors r+ |
Build succeeded |
2047: Add pool DB operation `removeRetiredPools`. r=jonathanknowles a=jonathanknowles # Issue Number #2018 # Overview Building on the work added in PRs #2024 and #2038, this PR: - [x] Adds a `removeRetiredPools` operation to the pool DB layer:<br><br> ```hs removeRetiredPools :: EpochNo -> stm [PoolRetirementCertificate] -- ^ Remove all pools with an active retirement epoch that is earlier -- than or equal to the specified epoch. -- -- Returns the retirement certificates of the pools that were removed. ``` - [x] Writes a bracketed `MsgRemovingRetiredPools` message to the log whenever the `removeRetiredPools` operation is called:<br><br> ``` Looking for pools that retired in or before epoch 1000. Removing the following retired pools: Pool 4355a46b with retirement epoch 999 Pool 53c234e5 with retirement epoch 999 Pool 121cfccd with retirement epoch 1000 Pool 917df332 with retirement epoch 1000 Finished removing retired pools. ``` # Further Work Before garbage collection can actually happen, the wallet needs to call `removeRetiredPools` at appropriate intervals. This work is deferred to a future PR. See issue #2019. Co-authored-by: Jonathan Knowles <[email protected]>
Issue Number
#2017
Overview
This PR:
removePools
operation to the pool DB layer:removePools
:Pool.DB.MVar
Pool.DB.SQLite
MsgRemovingPool
message to the log whenever a pool is removed: