-
Notifications
You must be signed in to change notification settings - Fork 213
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
SQL Schema #227
SQL Schema #227
Conversation
d9840e9
to
d05b30c
Compare
d05b30c
to
a8b4100
Compare
79d789e
to
20a80f6
Compare
just made compilation fix and rebased |
e3981de
to
55e7bbc
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.
So far so good! 👍
I've added a few comments to the review.
Also, there are a few parts that should be fixed to adhere to the coding standards. I've highlighted these in the comments, but I also created a PR (#246) with the problems fixed, which you can use directly if desired.
instance PersistField AddressScheme where | ||
toPersistValue = toPersistValue . schemeToBool | ||
fromPersistValue pv = do | ||
let err = T.pack $ "not a valid value: " <> show pv |
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.
You could probably write this as:
"not a valid value: " <> T.pack (show pv)
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.
👍
|
||
schemeToBool :: AddressScheme -> Bool | ||
schemeToBool Sequential = True | ||
schemeToBool Random = False |
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.
Perhaps this can be renamed to isSchemeSequential
. (Provide an equivalent isSchemeRandom
if desired.)
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... Just seeing this bit from the PR, but I don't think a Bool
is a wise choice for this one... We will likely introduce more schemes in the future (special ones for exchanges), and serializing this to Bool
might bite us later. Also, we already have a 3rd scheme that we use in the benchmarks Any
, and this will need to work with the DB as well...
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.
It's not used yet. We can turn it into an enum 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.
changed to data AddressScheme = Sequential | Random | Any
schemeToBool Sequential = True | ||
schemeToBool Random = False | ||
|
||
schemeFromBool :: Bool -> AddressScheme |
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.
Perhaps this deserves a comment, to explain the exact mapping that will take place. (Important for someone reading the haddock documentation.)
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.
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.
changed to data AddressScheme = Sequential | Random | Any
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 to clarify. If I'm a casual user of this function, it currently isn't clear how a given Bool
value will map onto an AddressScheme
. There are two possible mappings:
{True, False} -> {Sequential, Random}
{True, False} -> {Random, Sequential}
To understand precisely which mapping is being used, I'd have to dig into the source code, which kind of defeats the point.
I would recommend either:
- Removing this function (as this mapping is somewhat arbitrary).
- Renaming it (so that the exact mapping performed is clear from the name).
- Adding a haddock documentation comment to make the mapping explicit.
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.
Introduced data AddressScheme = Sequential | Random | Any
now relying on FromText
, ToText
- so basically opted for point 1 and 2 ;-)
98a325b
to
6bc357d
Compare
@jonathanknowles @KtorZ if we are ok with the current state, I can rebase the branch and merge it |
I haven't reviewed thoroughly any of this, just quick looks. I trust you guys on this :) |
6bc357d
to
58834a6
Compare
d219095
to
f2c65ad
Compare
-- blocks). | ||
-- | ||
-- TxMeta is specific to a wallet because multiple wallets may have the same | ||
-- transaction with different metdata values. The associated inputs and outputs |
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.
typo s/metdata/metadata/
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! corrected
f2c65ad
to
a1efedb
Compare
txMetaTableSlotId W.SlotId sql=slot_id | ||
txMetaTableAmount W.Coin sql=amount | ||
|
||
Primary txMetaTableTxId txMetaTableWalletId |
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 this can be shortend to only TxId
as every TxId
should be unique by itself and WalletId
shouldn't be needed to persist uniqness.
Also I don't think we need to have WalletId in this table
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.
addressed here #227 (comment)
-- of the transaction are in the TxIn and TxOut tables. | ||
TxMeta | ||
txMetaTableTxId TxId sql=tx_id | ||
txMetaTableWalletId W.WalletId sql=wallet_id |
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 we don't need reference to Wallet
(ie, WalletId
) in this table.
conceptually every TxMeta
is part of some transaction Tx
and every Tx
is part of some or many Wallet
s. If someone needs to query TxMeta
, like with he will most likely already have TxId
of the transaction that he is working with.
Also conceptually every Tx
might be part of multiple wallets: tx will show up in a wallet from which we sent the tx, and it might show up in a wallet to which we sent some tx. In a similar fashion - coresponding TxMeta
(as it is part of Tx
) might be part of multiple Wallet
s (sender and receiver wallet), not necessary one Wallet
as specified with WalletId
foreign key.
I might be on a wrong track but I would rather leave WalletId
out for now as at least conceptually it doesn't make sense to have it here.
Because I thought Wallet
and Tx
are in many-to-many relationship. Every transaction can be in multiple wallets, and every wallet can have multiple transactions
But instead of having WalletId
in all these tables related to Tx
(like TxMeta
, TxOut
, TxIn
, ...) why not create WalletTx
table that will keep all pairs of WalletId
and TxId
:
WalletTx
walletId WalletId
txId TxId
Primary walletId txId
this way we can have this many-to-many relationship in one place without having to manage WalletId
in every table that we have.
Maybe I am wrong :/ ? (I am still getting warmed up with sql)
txMetaTableAmount W.Coin sql=amount | ||
|
||
Primary txMetaTableTxId txMetaTableWalletId | ||
Foreign Wallet fk_wallet_tx_meta txMetaTableWalletId |
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 we should remove WalletId
from TxMeta
- see comment above.
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.
-- not the wallet. txInputTableTxId is referred to by TxMeta and PendingTx | ||
TxIn | ||
txInputTableTxId TxId sql=tx_id | ||
txInputTableWalletId W.WalletId sql=wallet_id |
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.
Similar answer as I said above - I think we should have WalletId
reference here
-- not the wallet. txOutputTableTxId is referred to by TxMeta and PendingTx | ||
TxOut | ||
txOutputTableTxId TxId sql=tx_id | ||
txOutputTableWalletId W.WalletId sql=wallet_id |
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.
Similar answer as I said above - I think we should have WalletId reference here
-- not the wallet. txInputTableTxId is referred to by TxMeta and PendingTx | ||
TxIn | ||
txInputTableTxId TxId sql=tx_id | ||
txInputTableWalletId W.WalletId sql=wallet_id |
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.
also I am not sure I understand why we have two TxId
s here ?
@akegalj Hi Ante, the schema will become clearer when we implement the insert/query methods.
Thanks for reviewing the substance of this PR rather than just its formatting. |
a1efedb
to
ca6be91
Compare
ah yes - didn't thought about this case |
ca6be91
to
a3ec3a6
Compare
our coding standards.
improve on percentage improve error msg comply with review remarks
The fromPersistentValue instance had an infinite loop.
Concluding import fixes Typo fix
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.
Mostly looks good to me.
This implementation will sattle when we start implementing queries on the DB and with that collect more experience.
What confuses me currently is last point raised by @jonathanknowles . There are bits in this implementation that look like:
instance Read TxId where
readsPrec _ = error "readsPrec stub needed for persistent"
and while I was going through persistent
and trying to understnad I could find the explanation why and where Read
will be used. Seems like this is a constrained from PersistentEntity
class https://hackage.haskell.org/package/persistent-2.5/docs/Database-Persist-Class.html#t:PersistEntity .
I would need further to dig the library to understand what for this is used as I can't clearly understand where it is used.
We are going to issue a PR in future to fix this
@jonathanknowles your comments in the review are addressed. As you do not feel ok to check it and we want to have it merged finally I click on |
comments addressed and we do not want to wait until next day
Relates to #147
Overview
Comments