-
Notifications
You must be signed in to change notification settings - Fork 214
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
Implement basic API functions for Byron-style wallets. #817
Implement basic API functions for Byron-style wallets. #817
Conversation
ab9372f
to
df6920e
Compare
ff00b64
to
1853d83
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.
looks good. Integration tests need to be expanded to assert also more for actual response also, not only response code. But this can be done in the next pr.
1853d83
to
f4b724b
Compare
bors try |
Thanks for reviewing this! 😄
It was indeed my intention to add more integration tests in further PRs. |
void | ||
. liftHandler | ||
. createWallet ctx wid name | ||
. mkRndState rootXPrv | ||
=<< liftIO (getStdRandom random) |
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.
just nitpicking - this supposed to increase readability? 🤓
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 think it's fairly readable if you read it from bottom to top. (The direction is consistent.)
We can read it like this:
- Take the output of
getStdRandom
and pass it tomkRndState
. - Take the output of
mkRndState
and pass it tocreateWallet
. - Take the output of
createWallet
and pass it toliftHandler
. - Finally, take the output of
liftHandler
and pass it tovoid
.
Of course, "step" 1 is slightly different from the others as getStdRandom
produces its output in a monadic context, so we need to bind (=<<
) rather than compose (`.').
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, I know how it flows ;-) And as I read from left to right, this structure forced me to do the opposite :-)
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, I know how it flows ;-) And as I read from left to right, this structure forced me to do the opposite :-)
Fair enough! But then surely the same applies to any composition of functions:
foo :: SomeComplicatedType
foo = f . g . h
In the above example, data flows (conceptually) from right to left. If we eta-expand, we get:
foo :: SomeComplicatedType
foo x = f (g (h x))
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 tend to agree with @paweljakubas on that one 😬 ... I don't mind much the function composition, but the bind >>=
makes the whole not very readable IMO.
listByronWallets _ = throwError err501 | ||
listByronWallets ctx = do | ||
wids <- liftIO $ Registry.keys re | ||
fmap fst . sortOn snd <$> |
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 sortOn (Down . snd)
?
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.
This should be fundamentally the same as listWallets
, which is defined as:
listWallets ctx = do
wids <- liftIO $ Registry.keys re
fmap fst . sortOn snd <$>
mapM (getWalletWithCreationTime mkApiWallet ctx) (ApiT <$> wids)
@@ -987,8 +987,14 @@ tearDown ctx = do | |||
let endpoint = "v2/wallets" </> wal ^. walletId | |||
d <- request @Value ctx ("DELETE", endpoint) None Empty | |||
expectResponseCode HTTP.status204 d | |||
respByron <- |
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.
we don't want to have separate tearByronDown
? And check if tearing down byron wallet do not affect wallet? Etc?
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.
@paweljakubas wrote:
we don't want to have separate tearByronDown? And check if tearing down byron wallet do not affect wallet? Etc?
@piotr-iohk What's your opinion on this?
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.
such tests (i.e. trying to delete byron with new endpoint and vice versa) I was planning to add in the ByronWallet.hs suite actually. They are planned in the spreadsheet for now:
https://docs.google.com/spreadsheets/d/1fadIA_j4nCd3FbylPo5J8K9Fy6tixSC2T9V3xHKuUvU/edit#gid=0
BYRON_DELETE
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.
ok, so tearDown
should be ok after that change. and there is no need for separate tearByronDown
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.
Looks fine to me!
@paweljakubas wrote:
Thanks for looking at this! |
bors r+ |
817: Implement basic API functions for Byron-style wallets. r=jonathanknowles a=jonathanknowles # Issue Number #774 (`restoreByronWallet`) #775 (`listByronWallets`) #776 (`getByronWallet`) #777 (`deleteByronWallet`) # Overview This PR implements all API functions _**apart from**_ those relating to _**migration**_. We have: - [x] Provided an implementation for [`restoreByronWallet`](#774). - [x] Provided an implementation for [`listByronWallets`](#775). - [x] Provided an implementation for [`getByronWallets`](#776). - [x] Provided an implementation for [`deleteByronWallet`](#777). - [x] Fixed **existing** integration tests for all of the above. # Not included in this PR Further integration tests: these will be included in _**further**_ sub-topic PRs. Co-authored-by: Jonathan Knowles <[email protected]>
tryBuild succeeded |
Build succeeded |
Issue Number
#774 (
restoreByronWallet
)#775 (
listByronWallets
)#776 (
getByronWallet
)#777 (
deleteByronWallet
)Overview
This PR implements all API functions apart from those relating to migration.
We have:
restoreByronWallet
.listByronWallets
.getByronWallets
.deleteByronWallet
.Not included in this PR
Further integration tests: these will be included in further sub-topic PRs.