-
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
Parameterise StakePools
API over apiPool type
#1738
Conversation
bors try |
|
||
-- | @StakePoolLayer@ is a thin layer ontop of the DB. It is /one/ value that | ||
-- can easily be passed to the API-server, where it can be used in a simple way. | ||
data StakePoolLayer e m = StakePoolLayer |
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.
Moved to Cardano.Pool.Jormungandr.Metrics
-> StakePoolLayer e IO | ||
-> IO [PoolId] | ||
-- ^ Known pools | ||
-- We could maybe replace this with a @IO (PoolId -> Bool)@ |
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.
No need to have a common StakePoolLayer
at this point. No need to have a common StakePool
type in core either.
We just need to make sure the target packages can provide a Handler (ListStakePool apiPool)
, for some apiPool
, and can provide this IO [PoolId]
.
tryBuild failed |
d5e4b84
to
11d2408
Compare
9fe0e15
to
2d547bd
Compare
@@ -183,13 +183,16 @@ import Servant.API.Verbs | |||
|
|||
type ApiV2 n = "v2" :> Api n | |||
|
|||
-- | The full cardano-wallet API. | |||
-- | |||
-- The API used in cardano-wallet-jormungandr may differ from this one. | |||
type Api n = |
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 assume this one can be fully moved to each target package, alongside the server instantiation.
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.
No! Sadly not easily, because we have a swagger spec in core!
My plan is to keep this type, but let jormungandr use a custom Api
type.
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.
Hmmm. Well no, we can also declare an "Api" type in the relevant test.
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.
Well no, we can also declare an "Api" type in the relevant test
That might make our test meaningless since if it is no longer testing the Api
type that is actually used.
I say we keep the haskell API in core
as the most important api, and test it, but not the jormungandr one.
…or, we define and test both APIs in core 🤔
…or, maybe one could do something with a ApiStakePool | ApiJormungandrStakePool
sum type 🤔
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.
Can sort out later.
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.
…or, maybe one could do something with a ApiStakePool | ApiJormungandrStakePool sum type thinking
Yeah, I thought of it. Since the stake pools are only something the server produces, it might just be okay to go down that path and fairly transparent for clients.
|
||
-- | @StakePoolLayer@ is a thin layer ontop of the DB. It is /one/ value that | ||
-- can easily be passed to the API-server, where it can be used in a simple way. | ||
data StakePoolLayer e m = StakePoolLayer |
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.
don't we want to have StakePoolLayer interface in core
? And in jormunagdr and shelley implementations of it?
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 believe we/you currently only need the knownStakePools :: IO [PoolId]
field to check that the pool we're joining actually exists. So I see no point in keeping the entire StakePoolLayer
then, since it would just be more work trying to unify the different pool-types under one common interface.
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.
a ok, got it . so now we will sneak IO [PoolId]
instead of StakePoolLayer
on wallet level. and just call it (with liftIO). and this will be knownPools
type argument...
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.
Yeah (see diff at #1738 (comment))
I was curious about using a IO (PoolId -> Bool)
also, but didn't do it.
bors r+ |
1738: Parameterise `StakePools` API over apiPool type r=Anviking a=Anviking # Issue Number ADP-311, #1718 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - [x] I parameterised `StakePools` API over `apiPool` - [x] I renamed `ApiStakePool` to `ApiJormungandrStakePool`, such that we can later introduce a haskell `ApiStakePool` - [x] I made the default `Api` type use `ApiJormungandrStakePool`. We should later switch to `ApiStakePool`, and update the swagger scheme such that it targets haskell, and not jormungandr. - [x] I moved `StakePoolLayer` to the jormungandr package. # Comments - I am keeping the Pool DB in core, since I think we still want it. But I have not thought about how it would work with shelley. - changelog: this is pure refactoring, but in combination with follow-up PRs this is a new feature. <!-- Additional comments or screenshots to attach if any --> <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <[email protected]> Co-authored-by: KtorZ <[email protected]>
Build failed |
bors r+ |
1738: Parameterise `StakePools` API over apiPool type r=Anviking a=Anviking # Issue Number ADP-311, #1718 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - [x] I parameterised `StakePools` API over `apiPool` - [x] I renamed `ApiStakePool` to `ApiJormungandrStakePool`, such that we can later introduce a haskell `ApiStakePool` - [x] I made the default `Api` type use `ApiJormungandrStakePool`. We should later switch to `ApiStakePool`, and update the swagger scheme such that it targets haskell, and not jormungandr. - [x] I moved `StakePoolLayer` to the jormungandr package. # Comments - I am keeping the Pool DB in core, since I think we still want it. But I have not thought about how it would work with shelley. - changelog: this is pure refactoring, but in combination with follow-up PRs this is a new feature. <!-- Additional comments or screenshots to attach if any --> <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <[email protected]> Co-authored-by: KtorZ <[email protected]>
bors r- |
Canceled |
Hydra will cache the previous build and it'll fail all-the-same. |
e240a99
to
08d6c86
Compare
bors try |
tryBuild failed |
Twice in a row, the unit tests on Windows aren't passing 🤔
|
I don't see anything obviously wrong on Windows in the changes from this PR though... |
bors r+ |
1738: Parameterise `StakePools` API over apiPool type r=Anviking a=Anviking # Issue Number ADP-311, #1718 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - [x] I parameterised `StakePools` API over `apiPool` - [x] I renamed `ApiStakePool` to `ApiJormungandrStakePool`, such that we can later introduce a haskell `ApiStakePool` - [x] I made the default `Api` type use `ApiJormungandrStakePool`. We should later switch to `ApiStakePool`, and update the swagger scheme such that it targets haskell, and not jormungandr. - [x] I moved `StakePoolLayer` to the jormungandr package. # Comments - I am keeping the Pool DB in core, since I think we still want it. But I have not thought about how it would work with shelley. - changelog: this is pure refactoring, but in combination with follow-up PRs this is a new feature. <!-- Additional comments or screenshots to attach if any --> <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <[email protected]> Co-authored-by: KtorZ <[email protected]>
bors r- |
Canceled |
08d6c86
to
1e27e7e
Compare
bors r+ |
1738: Parameterise `StakePools` API over apiPool type r=KtorZ a=Anviking # Issue Number ADP-311, #1718 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - [x] I parameterised `StakePools` API over `apiPool` - [x] I renamed `ApiStakePool` to `ApiJormungandrStakePool`, such that we can later introduce a haskell `ApiStakePool` - [x] I made the default `Api` type use `ApiJormungandrStakePool`. We should later switch to `ApiStakePool`, and update the swagger scheme such that it targets haskell, and not jormungandr. - [x] I moved `StakePoolLayer` to the jormungandr package. # Comments - I am keeping the Pool DB in core, since I think we still want it. But I have not thought about how it would work with shelley. - changelog: this is pure refactoring, but in combination with follow-up PRs this is a new feature. <!-- Additional comments or screenshots to attach if any --> <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <[email protected]> Co-authored-by: KtorZ <[email protected]>
Build failed |
bors r+ |
1738: Parameterise `StakePools` API over apiPool type r=Anviking a=Anviking # Issue Number ADP-311, #1718 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - [x] I parameterised `StakePools` API over `apiPool` - [x] I renamed `ApiStakePool` to `ApiJormungandrStakePool`, such that we can later introduce a haskell `ApiStakePool` - [x] I made the default `Api` type use `ApiJormungandrStakePool`. We should later switch to `ApiStakePool`, and update the swagger scheme such that it targets haskell, and not jormungandr. - [x] I moved `StakePoolLayer` to the jormungandr package. # Comments - I am keeping the Pool DB in core, since I think we still want it. But I have not thought about how it would work with shelley. - changelog: this is pure refactoring, but in combination with follow-up PRs this is a new feature. <!-- Additional comments or screenshots to attach if any --> <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <[email protected]> Co-authored-by: KtorZ <[email protected]>
Build failed |
This doesn't make sense, because this is not the actual code:
The build failure can't be cached, since master has changed? |
Ok, it is because of the merge 🤔 |
8ac875f
to
9c249fb
Compare
…askell - ApiStakePool -> ApiJormungandrStakePool - Move StakePoolLayer to the jormungandr package - add missing JSON golden file 'ApiJormungandrStakePool.json' - Move jorm listPools handler to server module - re-generate JSON golden file, in hope (commit from Matthias) Hoping to see the windows unit test timeout disappear
9c249fb
to
a42e9ae
Compare
bors r+ |
Build succeeded |
Issue Number
ADP-311, #1718
Overview
StakePools
API overapiPool
ApiStakePool
toApiJormungandrStakePool
, such that we can later introduce a haskellApiStakePool
Api
type useApiJormungandrStakePool
. We should later switch toApiStakePool
, and update the swagger scheme such that it targets haskell, and not jormungandr.StakePoolLayer
to the jormungandr package.Comments