-
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
Add TxMeta type #114
Add TxMeta type #114
Conversation
{ metaId :: !(Hash "Tx") | ||
-- FIXME: we might want to go for something more optimized than natural, | ||
-- like Word64 ? | ||
, depth :: !(Quantity "block" Natural) |
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.
do we want to keep types in Primitives
in their optimized form , thus opting for a bit more performant type like Word64
?
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.
Optimizations between Natural
vs Word64
is pointless at this stage. Writing an algorithm that goes in O(n²) will cause us some trouble. Using Natural
instead of Word64
won't probably have any noticeable effects on a wallet.
If so, we should measure it first and have a baseline to compare with.
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 will leave it to Natural
then because its a safer type. If there will be some evidence that this should be optimized more we can then measure and optimize
-- part alltogether. Node/core bits would still work optimally with | ||
-- Coin/Word64 | ||
-- but wallet bits could go a bit more abstract (and less optimized)? | ||
, amount :: !Coin |
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.
what about something less performant like Quantity "lovelace" Natural
for representing coin in wallet?
EDIT: in fact ^ is probably a bad idea because exchanges are also our clients and we do want to have performant types in wallet
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 guess the amount
is redundant with the transaction itself here. Not sure we do need to duplicate this information in the 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.
yes you are right - we can calculate this on demand. I thought this type will be used as a return type after calculation has been done already:
computeTxMeta :: Tx -> ... -> TxMeta
so in computeTxMeta
we would calculate this amount
. As I am not sure how this type will be used yet through the code - I can remove it untill its needed
newtype Timestamp = Timestamp | ||
-- NOTE: We could have gone for Microsecond from Data.Time.Units, but | ||
-- it seems like an overkill for now | ||
{ getTimestamp :: UTCTime |
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.
in the old wallet we used Microsecond
which at this point seems like not needed.
@@ -1,6 +1,7 @@ | |||
{-# LANGUAGE DataKinds #-} | |||
{-# LANGUAGE DeriveGeneric #-} | |||
{-# LANGUAGE DerivingStrategies #-} | |||
{-# LANGUAGE DuplicateRecordFields #-} |
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.
as proposed by @KtorZ , we are going to try to use generic-lens and light lensing as described here https://hackage.haskell.org/package/generic-lens with as little as possible:
^.
.~
%~
This is experimental
049fddd
to
a8d7c7d
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.
Some minor changes but over looks good 👍
{ metaId :: !(Hash "Tx") | ||
-- FIXME: we might want to go for something more optimized than natural, | ||
-- like Word64 ? | ||
, depth :: !(Quantity "block" Natural) |
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.
Optimizations between Natural
vs Word64
is pointless at this stage. Writing an algorithm that goes in O(n²) will cause us some trouble. Using Natural
instead of Word64
won't probably have any noticeable effects on a wallet.
If so, we should measure it first and have a baseline to compare with.
@@ -212,6 +220,30 @@ instance Buildable TxOut where | |||
instance Buildable (TxIn, TxOut) where | |||
build (txin, txout) = build txin <> " ==> " <> build txout | |||
|
|||
data TxMeta = TxMeta | |||
{ metaId :: !(Hash "Tx") |
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.
What about txId
here? That's what it is in the end, right ?
-- part alltogether. Node/core bits would still work optimally with | ||
-- Coin/Word64 | ||
-- but wallet bits could go a bit more abstract (and less optimized)? | ||
, amount :: !Coin |
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 guess the amount
is redundant with the transaction itself here. Not sure we do need to duplicate this information in the metadata.
b68f2e4
to
bd6b33c
Compare
Remove comments [101] Final polish of TxMeta 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.
LGTM
Issue Number
#101
Overview
TxMeta
datatypeComments
Nothing has been wired yet. This just creates datatype that will be used later on. Datatype is not set in stone as well and might change