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.

Sign up for GitHub

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

Jump to bottom

Parameterize Tx data-type over the wallet core engine (allowing to work with different representations) #451

Merged
merged 3 commits into from
Jun 22, 2019
Merged

Parameterize Tx data-type over the wallet core engine (allowing to work with different representations) #451

merged 3 commits into from
Jun 22, 2019

Commits on Jun 21, 2019

  1. Parameterize wallet core over the transaction data-type 

    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
    KtorZ committed Jun 21, 2019
    Configuration menu
    Copy the full SHA
    1305e29 View commit details
    Browse the repository at this point in the history

  2. re-generate nix machinery

    @KtorZ
    KtorZ committed Jun 21, 2019
    Configuration menu
    Copy the full SHA
    1f74545 View commit details
    Browse the repository at this point in the history

  3. ignore shared module between bench and unit tests

    @KtorZ
    KtorZ committed Jun 21, 2019
    Configuration menu
    Copy the full SHA
    ad34c83 View commit details
    Browse the repository at this point in the history