Add StorageList support in decl_storage by sorpaas · Pull Request #2261 · paritytech/substrate

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

sorpaas · 2019-04-12T01:06:49Z

Add back storage list support in decl_storage macro. Can fix issues like #2228.

A QoL function StorageList::push is also added.

xlc · 2019-04-12T01:32:10Z

 #[cfg_attr(feature = "std", derive(Decode, Debug, Serialize))]
 pub enum StorageFunctionType {
 	Plain(DecodeDifferentStr),
+	List(DecodeDifferentStr),


please put this to the end to improve backward compatibility

xlc · 2019-04-12T01:35:23Z


+	/// Push a new item to the list.
+	fn push(item: &T);
+


no pop method? how do I delete the last item?

bkchr · 2019-04-12T06:59:48Z

I thought we won't bring back storage list because of the performance issues. See here #772

tomusdrw · 2019-04-12T07:46:43Z

We do have linked_map now that should be more efficient

tomusdrw · 2019-04-12T08:08:38Z

To clarify on my "more efficient" comment, after discussing that with @bkchr .
linked_map and StorageList have many similarities and in most cases the performance would be similar, so iterating over unbounded collection inside runtime is still not recommended.

However:

linked_map offers arbitrary (sparse) keys (not only a consistent range of 0..len)
That makes removals more efficient (no need to re-order) and also makes the key persistent, hence reliable

xlc · 2019-04-12T08:59:11Z

I see some use cases of storage list. Every data structure have its trade offs.
Storage list can be used as a stack, an append only storage (like events). It use less storage than linked map (which needs to store next and prev for every item).

I think Substrate should offer (secure and safe) options and guidances to help developers to make right decisions.

bkchr · 2019-04-12T11:34:35Z

You will need to iterate events at the end of each block and that will create a lot of database accesses.

xlc · 2019-04-12T11:41:48Z

Why do I need to iterate events? To conver to Vec for compatibility reason? I believe polkadotjs is able to somehow detects the format and handle both cases just like metadata versions

bkchr · 2019-04-12T11:48:11Z

Yeah, good point^^

sorpaas · 2019-04-13T00:52:01Z

@bkchr

You will need to iterate events at the end of each block and that will create a lot of database accesses.

It does not necessarily need any database access. For something like Events, things are directly stored in the overlay. We only need to generate trie structure when storage_root is called, which usually happens after Events are killed.

bkchr · 2019-04-13T05:44:55Z

Yeah I know that we don't always access the real database. Nevertheless, we still need to have 1 lookups + 2 writes for storing one event.

(events are also part of the storage root, as they stay for the client to inspect them)

gavofyork · 2019-04-19T15:18:01Z

Indeed. Events are not free - the stick around until the next block and therefore bloat the trie and increase hashing required and then you'll need to iterate over all of the last block's events to delete them, increasing I/O.

bkchr · 2019-04-19T15:20:16Z

Events bottleneck is also already fixed in master.

So how do we continue with this one? Close?

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Add StorageList support in decl_storage
cb8a9a2

sorpaas added the A0-please_review Pull request needs code review. label Apr 12, 2019

sorpaas requested a review from bkchr April 12, 2019 01:06

devops-parity added the A4-gotissues label Apr 12, 2019

Bump impl version
58bf3c6

sorpaas removed the A4-gotissues label Apr 12, 2019

xlc reviewed Apr 12, 2019
View reviewed changes

Add pop for StorageList and address other grumbles
b8014f9

xlc mentioned this pull request Apr 16, 2019
Start supporting double map polkadot-js/api#843
Merged

sorpaas closed this Apr 19, 2019

arkpar deleted the sp-storage-list branch April 23, 2020 18:12

Uh oh!

Conversation

sorpaas commented Apr 12, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bkchr commented Apr 12, 2019

Uh oh!

tomusdrw commented Apr 12, 2019

Uh oh!

tomusdrw commented Apr 12, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xlc commented Apr 12, 2019

Uh oh!

bkchr commented Apr 12, 2019

Uh oh!

xlc commented Apr 12, 2019

Uh oh!

bkchr commented Apr 12, 2019

Uh oh!

sorpaas commented Apr 13, 2019

Uh oh!

bkchr commented Apr 13, 2019

Uh oh!

gavofyork commented Apr 19, 2019

Uh oh!

bkchr commented Apr 19, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

sorpaas commented Apr 12, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bkchr commented Apr 12, 2019

Uh oh!

tomusdrw commented Apr 12, 2019

Uh oh!

tomusdrw commented Apr 12, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xlc commented Apr 12, 2019

Uh oh!

bkchr commented Apr 12, 2019

Uh oh!

xlc commented Apr 12, 2019

Uh oh!

bkchr commented Apr 12, 2019

Uh oh!

sorpaas commented Apr 13, 2019

Uh oh!

bkchr commented Apr 13, 2019

Uh oh!

gavofyork commented Apr 19, 2019

Uh oh!

bkchr commented Apr 19, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

tomusdrw commented Apr 12, 2019•
edited
Loading

tomusdrw commented Apr 12, 2019•
edited
Loading

tomusdrw commented Apr 12, 2019•
edited
Loading