Skip to content
This repository has been archived by the owner on Mar 23, 2021. It is now read-only.

Clean up storage #2818

Merged
merged 6 commits into from Jun 12, 2020
Merged

Clean up storage #2818

merged 6 commits into from Jun 12, 2020

Conversation

tcharding
Copy link
Collaborator

@tcharding tcharding commented Jun 10, 2020

Refactor the storage module, this one is kinda big. Patches are discreet and explained in their commit logs.

Patch 1 - Fix up use statements
Patch 2 - Shorten the qualified path usage
Patch 3 - Refactor load of the spawn::Swap type. This refactor uses the style of generics as done for Save<CreatedSwap<A, B>>. Adds a couple of macros also, specifically one is added because the trait bounds for diesel trait BelongingtoDsl was too complicated to work out.
Patch 4 - Creates a sub-module http_api under storage and puts the load imlps for AliceSwap and BobSwap in it. Refactors heavily.
Patch 5 - trivial code re-order.

Patches 4 and 5 are the big ones, the diffs are not that easy to read - may be better to check out the branch locally and have a look at whats going on.

If there is anything I can do to make review easier for future reviews of these big refactor PRs please say.

Thanks

&self,
id: LocalSwapId,
) -> anyhow::Result<spawn::Swap<herc20::Params, halight::Params>> {
) -> anyhow::Result<(Swap, Herc20, Halight, Option<SecretHash>)> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you make Herc20 and Halight generic here with a trait-bound to make the belonging_to method available?

Copy link
Contributor

Choose a reason for hiding this comment

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

Even though it is just a private method, having a struct with field names would make it clearer that .1 is alpha and .2 is beta.

If we establish this and succeed in making this generic, this would be a nice place to do #2781.

Copy link
Contributor

Choose a reason for hiding this comment

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

As a follow-up, we can define traits for:

  • derive_or_unwrap_secret_hash
  • build_herc20_params
  • build_halight_params
  • build_hbit_params

and make one generic impl that loads Params, similar to what we did for Save !

Copy link
Contributor

Choose a reason for hiding this comment

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

Can all be a follow-up so we don't make this one too big.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks for the review, will process this information and work in what I can make work :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Even though it is just a private method, having a struct with field names would make it clearer that .1 is alpha and .2 is beta.

These are not sides (alpha/beta), this function returns the trading pair - it is agnostic to the side.

cnd/src/storage/http_api.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@luckysori luckysori left a comment

Choose a reason for hiding this comment

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

This is very good!

wrapper_types::custom_sql_types::Text,
ForSwap, NoHalightRedeemIdentity, NoHalightRefundIdentity, NoHerc20RedeemIdentity,
NoHerc20RefundIdentity, NoSecretHash, Save, Sqlite,
self, ForSwap, Halight, Hbit, Herc20, NoHalightRedeemIdentity, NoHalightRefundIdentity,
Copy link
Contributor

Choose a reason for hiding this comment

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

🤔 This patch doesn't introduce the problem, but I find the names Halight, Hbit and Herc20 too general. Even if you're in the context of the storage module. I would find it clearer if we used them with a more qualified name, e.g table::Halight or even db::table::Halight (sorry I like long names [sometimes]).

Copy link
Contributor

Choose a reason for hiding this comment

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

db::<protocol-name> would be better, but still a bit lacking imo.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have to disagree with you here mate. Apart from the fact that I always favour short names; the storage module is different in that it fully 'owns' the database, so bringing types from the db into scope is the natural thing to do IMO. The fact that the new tables are in the tables module is not important, when I'm writing/reading code in the storage module it is just like we are in the db layer so all the types are implicitly db types. Does that make sense? We don't have to agree :) (on this point, that's why I originally brought SecretHash into scope from the db and used comit::SecretHash when needed, you did it the other way around and I left it as such when I rebased :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I'm okay with this even if I don't love it 😉

Copy link
Contributor

Choose a reason for hiding this comment

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

the storage module is different in that it fully 'owns' the database

Would be nice to express that in our module hierarchy.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh, I like that.

db and seed being private scope modules under storage. Will wait for the remove of rfc003 before doing this, adding to my TODO list.

spawn,
swap_protocols::state::Get,
LocalSwapId, Protocol, Role, Side, SwapContext,
spawn, Get, LocalSwapId, Protocol, Role, RootSeed, Side, SwapContext,
Copy link
Contributor

Choose a reason for hiding this comment

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

🙃 Very minor nit, but importing Get by itself is not great. Maybe it doesn't matter because it's just in the imports section, but I would rather see something like state::Get.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ok, I'm good with that. Will do.

cnd/src/storage/http_api.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

Very nice work man!

Review was super easy patch-by-patch, really enjoyed that :)

Thanks!

let swap: Swap = swaps::table
.filter(swaps::local_swap_id.eq(key))
.first(conn)?;
pub trait LoadTables<A, B> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Rename to LoadProtocolTables?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yep can do.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

On second thoughts, this does not lead just the protocol tables, it also includes the Swaps table and the SecretHash table. Admittedly this is a very generic name and will likely clash next time we need to load a set of different tables. Leaving as is for now.

Comment on lines +242 to +184
alpha.assert_side(Side::Alpha)?;
beta.assert_side(Side::Beta)?;
Copy link
Contributor

Choose a reason for hiding this comment

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

This is the only place where we use assert_side right?

Why not just:

Suggested change
alpha.assert_side(Side::Alpha)?;
beta.assert_side(Side::Beta)?;
if alpha.side.0 != Side::Alpha || beta.side.0 != Side::Beta {
anyhow::bail!("...")
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I had that first but it didn't build. Unless I'm mistaken, we don't know the types here so we need to use a trait.

Copy link
Contributor

Choose a reason for hiding this comment

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

This should work. You are inside a macro so the code will just expand. Isn't the field called side for all tables?

@tcharding
Copy link
Collaborator Author

bors r+

@bors
Copy link
Contributor

bors bot commented Jun 12, 2020

Merge conflict.

tcharding added 6 commits June 12, 2020 12:46
The import statements in the storage module are too noisy.

The storage module fully 'owns' the database, it makes sense to just
bring all the types from the db into scope.

In an effort to move the whole code base in this direction we can also
export `Get` up to the root level module and import it without the
qualified path.
Now we have the tables types pub used in the db module we can shorten
the qualified path used to differentiate the db `SecretHash` from the
comit crate `SecretHash`.
Refactor the impl blocks for AliceSwap/BobSwap types by:

- Move all the code for loading http_api module types into a
  sub-module of storage

- Add generic conversion traits for creating the `Finalized[AsFoo]`
  types

- Add From impls for asset conversion

- Use recently added load_tables method to get the data we need
  instead of inline access to the database
`Get` is a bit unclear, lets qualify the import with it's module.

Use qualified path `state::Get` when bring `Get` into scope.
@mergify
Copy link
Contributor

mergify bot commented Jun 12, 2020

bors r+

@bors
Copy link
Contributor

bors bot commented Jun 12, 2020

Build succeeded:

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants