Parameterize Tx data-type over the wallet core engine (allowing to work with different representations)
#451
Conversation
| @@ -163,16 +163,18 @@ test-suite unit | |||
| exitcode-stdio-1.0 | |||
| hs-source-dirs: | |||
| test/unit | |||
| test/shared | |||
There was a problem hiding this comment.
I've factored out common stuff related to DummyTarget in a shared module.
| instance Buildable Tx where | ||
| build (Tx ins outs) = mempty | ||
| <> blockListF' "~>" build ins | ||
| <> blockListF' "<~" build outs |
There was a problem hiding this comment.
Moved into http-bridge/src/Cardano/Wallet/HttpBridge/Primitive/Types.hs
| } | ||
| , transactions = [] | ||
| } | ||
|
|
There was a problem hiding this comment.
Factored out into Moved into Cardano/Wallet/DummyTarget/Primitive/Types.hs
| where | ||
| decodingError _ = TextDecodingError | ||
| "Unable to decode Address: expected Base16 encoding" | ||
|
|
There was a problem hiding this comment.
Factored out into Moved into Cardano/Wallet/DummyTarget/Primitive/Types.hs
| , prevBlockHash = Hash "genesis" | ||
| } | ||
| , transactions = [] | ||
| } |
There was a problem hiding this comment.
Factored out into Moved into Cardano/Wallet/DummyTarget/Primitive/Types.hs
| } | ||
|
|
||
| instance TxId DummyTarget where | ||
| txId = Hash . B8.pack . show |
There was a problem hiding this comment.
Factored out into Moved into Cardano/Wallet/DummyTarget/Primitive/Types.hs
|
|
||
| instance KeyToAddress DummyTarget where | ||
| keyToAddress = Address . unXPub . getKey | ||
|
|
There was a problem hiding this comment.
Factored out into Moved into Cardano/Wallet/DummyTarget/Primitive/Types.hs
| \ - ~> 1st c29d3ea0...13862214\n\ | ||
| \ <~ 3823755953610 @ 82d81858...aebb3709\n\ | ||
| \ <~ 19999800000 @ 82d81858...37ce9c60\n" | ||
| === pretty @_ @Text block |
There was a problem hiding this comment.
Moved into http-bridge unit tests
KtorZ
force-pushed
the
KtorZ/parameterize-tx
branch
2 times, most recently
from
5fdf0ba to
849f5a1
Compare
This commit defines a new abstraction layer via the class
class (NFData (Tx t), Show (Tx t), Ord (Tx t)) => DefineTx t where
type Tx t :: *
txId :: Tx t -> Hash "Tx"
inputs :: Tx t -> [TxIn]
outputs :: Tx t -> [TxOut]
This allows for leaving the transaction shape rather 'open' and
define by whoever is implementing the wallet layer, so long as
it provides a few accessors on the transaction type and some
mandatory type-classes used across the wallet.
This allows for supporting both cardano-http-bridge and jormungandr
at the same time (and likely, add support for shelley-haskell
without too much issues).
One point remains fairly hard to abstract at the moment and it's the
DBLayer, or more exactly, the SQLite implementation. Since it's defined
in `cardano-wallet-core`, we can't -- in theory -- assume anything
about the shape of the transaction data-type. This makes it hard to
prepare the shape of the database without any prior knowledge of the
data-type. We cheat a bit by defining an extra class in the SQLite
module:
class DefineTx t => PersistTx t where
resolvedInputs :: Tx t -> [(W.TxIn, Maybe W.Coin)]
mkTx :: [(W.TxIn, Maybe W.Coin)] -> [W.TxOut] -> Tx t
This assumes a specific shape for the transaction but is still flexible
enough that this assumption isn't too pervasive in the SQLite code. In
practice, this is _sufficient_ for our needs, so we may not bother any
further.
KtorZ
force-pushed
the
KtorZ/parameterize-tx
branch
from
849f5a1 to
1f74545
Compare
KtorZ
force-pushed
the
KtorZ/parameterize-tx
branch
from
1eebd1f to
ad34c83
Compare
| txInputTableOrder Int sql=order | ||
| txInputTableSourceTxId TxId sql=source_id | ||
| txInputTableSourceIndex Word32 sql=source_index | ||
| txInputTableSourceAmount W.Coin Maybe sql=source_amount default=NULL |
There was a problem hiding this comment.
did this slip through? Looks like something for another PR
There was a problem hiding this comment.
Nope, unfortunately. The syntax is a bit weird but that's how we define nullable column with the persistent DSL. This allows for defining a single db schema for both http-bridge and jormungandr.
The difference is actually so small here that I thought this would be better than maintaining two distinct database tables.
Issue Number
#219
Overview
This PR defines a new abstraction layer via the class
This allows for leaving the transaction shape rather 'open' and
define by whoever is implementing the wallet layer, so long as
it provides a few accessors on the transaction type and some
mandatory type-classes used across the wallet.
This allows for supporting both cardano-http-bridge and jormungandr
at the same time (and likely, add support for shelley-haskell
without too much issues).
One point remains fairly hard to abstract at the moment and it's the
DBLayer, or more exactly, the SQLite implementation. Since it's defined
in
cardano-wallet-core, we can't -- in theory -- assume anythingabout the shape of the transaction data-type. This makes it hard to
prepare the shape of the database without any prior knowledge of the
data-type. We cheat a bit by defining an extra class in the SQLite
module:
This assumes a specific shape for the transaction but is still flexible
enough that this assumption isn't too pervasive in the SQLite code. In
practice, this is sufficient for our needs, so we may not bother any
further.
Define new modules to host the
Txdata-types used by different targetsTxas we know it)Tx, butTxInhave an additionalCoinattached to them, so they are closer to what we used to callResolvedInputs).Disabled Jormungandr golden tests for TxId
The tests golden strings were not generated using jcli but using our own implementation, so they aren't testing anything. For now disabled, but will re-work them and generate strings from jcli.
Comments