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

Relocate properties to DBSpec for further sharing #270

Merged
merged 3 commits into from
May 16, 2019

Conversation

paweljakubas
Copy link
Contributor

Issue Number

#154

Overview

  • I have relocated MVar properties to DBSpec in order to further share them with SqliteSpec

Comments

@paweljakubas paweljakubas requested review from KtorZ and rvl May 16, 2019 08:35
, DummyTarget
, DummyStateMVar (..)
, dbPropertyTests
, prop_readAfterPutBoundary
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is that one 🤔 ?

Copy link
Contributor Author

@paweljakubas paweljakubas May 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, this is for SqliteSpec. There was an error when put . read if status is Restoring Quantity 100 as this was written as Ready

Copy link
Contributor Author

@paweljakubas paweljakubas May 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

namely, it will be used for check that Restoring . Quantity 100 upon write results in Ready upon read test

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not include it in the dbPropertyTests, that should hold for the MVar too no ?

Copy link
Contributor Author

@paweljakubas paweljakubas May 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because, it fails -

  1) Cardano.Wallet.DB.MVar, put . read yields a result, check that Restoring . Quantity 100 upon write results in Ready upon read
       Falsifiable (after 1 test):
         (PrimaryKey (WalletId {getWalletId = 8adfe5c94630e8ae4b47d6e4c9363ef31f5fa36b}),WalletMetadata {name = WalletName {getWalletName = "bulbazaur"}, passphraseInfo = Just (WalletPassphraseInfo {lastUpdatedAt = 1864-05-09 09:25:31.730365313989 UTC}), status = Ready, delegation = NotDelegating})
       expected: Just (WalletMetadata {name = WalletName {getWalletName = "bulbazaur"}, passphraseInfo = Just (WalletPassphraseInfo {lastUpdatedAt = 1864-05-09 09:25:31.730365313989 UTC}), status = Ready, delegation = NotDelegating})
        but got: Just (WalletMetadata {name = WalletName {getWalletName = "bulbazaur"}, passphraseInfo = Just (WalletPassphraseInfo {lastUpdatedAt = 1864-05-09 09:25:31.730365313989 UTC}), status = Restoring (Quantity (Percentage {getPercentage = 100})), delegation = NotDelegating})

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, something's wrong then 😄 ! Probably in the generator itself actually. Not sure that Restoring (Quantity 100) should be an allowed value. I thought about that the other day and we do construct the wallet restoration state "by hand". We'd probably be better off having some clear API for manipulating this type, which enforces that the status can't be above 99.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Restoring (Quantity (Percentage {getPercentage = 100}) is stored as it is, but in Sqlite (at least how we implemented it) it was represented as Ready. This is because of how status 100 is handled in the code (maybe we will change it, and then this property is not needed)

Copy link
Contributor Author

@paweljakubas paweljakubas May 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I will remove this property and reintroduce it later (if needed) !
then customedGen will be removed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, customizedGen makes sense - will recover it

module Cardano.Wallet.DBSpec
( spec
, DummyTarget
, DummyStateMVar (..)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that's MVar-specific, shouldn't it be with DB.MVarSpec ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had problems with Arbitrary instances needed in DbSpec after relocation. To avoid them I put every instances in DBSpec...Maybe it was too quick decision

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's quite minor, but yes, I think at least DummyStateMVar could just be with the MVar specs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair argument - done

@paweljakubas paweljakubas force-pushed the paweljakubas/154/db-unit-tests-sharing branch 2 times, most recently from 1ef0525 to 34306da Compare May 16, 2019 12:02
@paweljakubas paweljakubas merged commit 869ce8f into master May 16, 2019
@iohk-bors iohk-bors bot deleted the paweljakubas/154/db-unit-tests-sharing branch May 16, 2019 14:48
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.

None yet

2 participants