Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Use EncodeLike for storages traits #3676

Merged
merged 21 commits into from
Oct 1, 2019
Merged

Use EncodeLike for storages traits #3676

merged 21 commits into from
Oct 1, 2019

Conversation

gui1117
Copy link
Contributor

@gui1117 gui1117 commented Sep 24, 2019

Fix #1876

Done:

  • this makes storage map, linked map and else use encodelike instead of there direct argument.

Critics:

  • There is usage of Ref::from in map and linkedmap, with some refactor we can avoid those and derive the final key only once.
    I think we could do refactoring of this in a following PR
  • ppl have to bound FullCodec or EncodeLike in their associated type of their module.

@gui1117 gui1117 changed the title Use EncodeLike for in our storages Use EncodeLike for storages traits Sep 24, 2019
@gui1117 gui1117 requested a review from bkchr September 24, 2019 12:15
@gui1117 gui1117 added A3-in_progress Pull request is in progress. No review needed at this stage. A0-please_review Pull request needs code review. and removed A3-in_progress Pull request is in progress. No review needed at this stage. labels Sep 24, 2019
}

fn clear_key_owner(id: KeyTypeId, key_data: &[u8]) {
<KeyOwner<T>>::remove(DEDUP_KEY_PREFIX, &(id, key_data.to_vec()));
<KeyOwner<T>>::remove(&DEDUP_KEY_PREFIX, &(id, key_data.to_vec()));
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
<KeyOwner<T>>::remove(&DEDUP_KEY_PREFIX, &(id, key_data.to_vec()));
<KeyOwner<T>>::remove(&DEDUP_KEY_PREFIX, &(id, key_data));

This file is actually the reason I started with EncodeLike :D

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done, and tried to catch up most of them

@gui1117 gui1117 added A3-in_progress Pull request is in progress. No review needed at this stage. and removed A0-please_review Pull request needs code review. labels Sep 24, 2019
@gui1117
Copy link
Contributor Author

gui1117 commented Sep 24, 2019

also maybe I could check for compile time regression,

EDIT: I didn't make a proper full check but seems fine

@gui1117 gui1117 added A0-please_review Pull request needs code review. and removed A3-in_progress Pull request is in progress. No review needed at this stage. labels Sep 27, 2019
@@ -929,7 +929,7 @@ impl<T: Trait> Module<T> {
} else {
<DispatchQueue<T>>::append_or_insert(
now + info.delay,
[Some((info.proposal, index))].into_iter()
&[Some((info.proposal, index))][..]
Copy link
Member

Choose a reason for hiding this comment

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

I think that makes no real difference, but okay.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no it will compile with something like:

the trait bound `Iter<'_, std::option::Option<(<T as Trait>::Proposal, u32)>>: EncodeLike<std::vec::Vec<std::option::Option<(<T as Trait>::Proposal, u32)>>>` is not satisfied

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm at some point we should derive EncodeLike for standard iterator structures.

@@ -816,7 +816,7 @@ impl<T: Trait> Module<T> {
if set_len + 1 == VOTER_SET_SIZE {
NextVoterSet::put(next + 1);
}
<Voters<T>>::append_or_insert(next, [Some(who.clone())].into_iter())
<Voters<T>>::append_or_insert(next, &[Some(who.clone())][..])
Copy link
Member

Choose a reason for hiding this comment

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

You are still cloning.

Copy link
Contributor Author

@gui1117 gui1117 Oct 1, 2019

Choose a reason for hiding this comment

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

yes because satisfying both iterator constrained and EncodeLike<Vec<T>> is hard.

srml/support/src/storage/mod.rs Outdated Show resolved Hide resolved
@@ -839,13 +840,17 @@ mod test_append_and_len {
#[test]
fn append_or_put_works() {
with_externalities(&mut TestExternalities::default(), || {
let _ = MapVec::append_or_insert(1, [1, 2, 3].iter());
let _ = MapVec::append_or_insert(1, [4, 5].iter());
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this work as well?

Co-Authored-By: Bastian Köcher <bkchr@users.noreply.github.com>
@@ -159,7 +159,7 @@ decl_module! {
let id = Self::next_asset_id();
<NextAssetId<T>>::mutate(|id| *id += One::one());

<Balances<T>>::insert((id, origin.clone()), total);
<Balances<T>>::insert((id, &origin), total);
Copy link
Contributor

Choose a reason for hiding this comment

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

cc @shawntabrizi in v2 for kitties tutorial: the original issue of the PR references the v2 tutorial. If keys of type tuple are still around they can be refactored now

Copy link
Member

Choose a reason for hiding this comment

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

awesome!

let new_prop = (index, (*proposal).clone(), who);
<PublicProps<T>>::append_or_put([new_prop].into_iter());
let new_prop = (index, proposal, who);
<PublicProps<T>>::append_or_put(&[Ref::from(&new_prop)][..]);
Copy link
Contributor

Choose a reason for hiding this comment

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

If can be refactored and you think it is worth it, would be good to have a small issue for it after the PR is merged 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ref from inside srml-support/storage/generator like in the implementation of linkedmap and map.
here it is legit. no super beautiful indeed.

// Next element key in storage (None for the last element)
next: Option<NKey>,
// The key of the linkage this type encode to
phantom: core::marker::PhantomData<Key>,
Copy link
Contributor

Choose a reason for hiding this comment

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

import from rstd for consistency?

Copy link
Contributor

@kianenigma kianenigma left a comment

Choose a reason for hiding this comment

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

I will revisit this at a later point since I could not read some parts in detail; looks to be already great.

@bkchr bkchr merged commit db417ff into master Oct 1, 2019
@bkchr bkchr deleted the gui-encodelike-storage2 branch October 1, 2019 17:45
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Avoid some clone when creating keys to use in StorageMap methods
4 participants