Skip to content
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

Merged
merged 10 commits into from
Oct 15, 2019

Conversation

jonathanknowles
Copy link
Member

@jonathanknowles jonathanknowles commented Oct 14, 2019

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:

Not included in this PR

Further integration tests: these will be included in further sub-topic PRs.

@jonathanknowles jonathanknowles self-assigned this Oct 14, 2019
@jonathanknowles jonathanknowles force-pushed the jonathanknowles/basic-byron-wallet-functions branch 4 times, most recently from ab9372f to df6920e Compare October 15, 2019 10:04
iohk-bors bot added a commit that referenced this pull request Oct 15, 2019
@jonathanknowles jonathanknowles force-pushed the jonathanknowles/basic-byron-wallet-functions branch from ff00b64 to 1853d83 Compare October 15, 2019 13:05
iohk-bors bot added a commit that referenced this pull request Oct 15, 2019
@jonathanknowles jonathanknowles changed the title WIP: Basic Byron Wallet Functions Basic Byron Wallet Functions Oct 15, 2019
@jonathanknowles jonathanknowles changed the title Basic Byron Wallet Functions Implement basic API functions for Byron-style wallets. Oct 15, 2019
Copy link
Contributor

@piotr-iohk piotr-iohk left a 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.

@jonathanknowles jonathanknowles force-pushed the jonathanknowles/basic-byron-wallet-functions branch from 1853d83 to f4b724b Compare October 15, 2019 13:39
@jonathanknowles
Copy link
Member Author

bors try

iohk-bors bot added a commit that referenced this pull request Oct 15, 2019
@jonathanknowles
Copy link
Member Author

looks good.

Thanks for reviewing this! 😄

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.

It was indeed my intention to add more integration tests in further PRs.

@cardano-foundation cardano-foundation deleted a comment from iohk-bors bot Oct 15, 2019
@cardano-foundation cardano-foundation deleted a comment from iohk-bors bot Oct 15, 2019
@cardano-foundation cardano-foundation deleted a comment from iohk-bors bot Oct 15, 2019
iohk-bors bot added a commit that referenced this pull request Oct 15, 2019
@cardano-foundation cardano-foundation deleted a comment from iohk-bors bot Oct 15, 2019
Comment on lines +788 to +792
void
. liftHandler
. createWallet ctx wid name
. mkRndState rootXPrv
=<< liftIO (getStdRandom random)
Copy link
Contributor

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? 🤓

Copy link
Member Author

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:

  1. Take the output of getStdRandom and pass it to mkRndState.
  2. Take the output of mkRndState and pass it to createWallet.
  3. Take the output of createWallet and pass it to liftHandler.
  4. Finally, take the output of liftHandler and pass it to void.

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 (`.').

Copy link
Contributor

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 :-)

Copy link
Member Author

@jonathanknowles jonathanknowles Oct 15, 2019

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))

Copy link
Member

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 <$>
Copy link
Contributor

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) ?

Copy link
Member Author

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 <-
Copy link
Contributor

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?

Copy link
Member Author

@jonathanknowles jonathanknowles Oct 15, 2019

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?

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

@paweljakubas paweljakubas left a 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!

@jonathanknowles
Copy link
Member Author

jonathanknowles commented Oct 15, 2019

@paweljakubas wrote:

Looks fine to me!

Thanks for looking at this!

iohk-bors bot added a commit that referenced this pull request Oct 15, 2019
@jonathanknowles jonathanknowles removed the request for review from KtorZ October 15, 2019 16:08
@jonathanknowles
Copy link
Member Author

bors r+

iohk-bors bot added a commit that referenced this pull request Oct 15, 2019
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]>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 15, 2019

try

Build succeeded

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 15, 2019

Build succeeded

@iohk-bors iohk-bors bot merged commit 8ae6769 into master Oct 15, 2019
@KtorZ KtorZ deleted the jonathanknowles/basic-byron-wallet-functions branch October 16, 2019 12:11
@KtorZ KtorZ added this to the Byron Wallet Support milestone Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants