feat: Add PrimaryKey implementation example for custom types#93
feat: Add PrimaryKey implementation example for custom types#93bullet-tooth wants to merge 1 commit intoCosmWasm:mainfrom
Conversation
| Denom::Native(name) => (NATIVE_PREFIX, name.as_bytes()), | ||
| Denom::Cw20(addr) => (CW20_PREFIX, addr.as_bytes()), | ||
| }; | ||
| vec![Key::Val8([prefix]), Key::Ref(value)] |
There was a problem hiding this comment.
Question for maintainers: From the selectivity perspective, mb, is it better to write the value first as a prefix and after its type (which is either 1 or 2 in our case)?
There was a problem hiding this comment.
That would cause iteration order to be very unintuitive. I suspect prefixing is better.
|
Hi! It's definitely a good idea to document primary key implementation. Thank you for doing this and for your patience. A much better place for this would be our official guide: https://docs.cosmwasm.com/cw-storage-plus/containers/map Would you be open to porting the documentation work there? Otherwise, if you reduce the scope of this PR to just making the helper functions public, I can take it over at some point and add the documentation to the guide. |
|
@uint sure, thanks for your comments. By the way, it would be great to review my implementation because I'm not 100% sure it's optimal and production-ready. |
| Denom::Native(name) => (NATIVE_PREFIX, name.as_bytes()), | ||
| Denom::Cw20(addr) => (CW20_PREFIX, addr.as_bytes()), | ||
| }; | ||
| vec![Key::Val8([prefix]), Key::Ref(value)] |
There was a problem hiding this comment.
As far as I understand, if we split these two elements as separate "subkeys", your prefix will end up length-prefixed itself.
It might be better to return a one-element vector here, combining the prefix with the value by hand. Then other methods would need to be adjusted accordingly and KeyDeserialize::KEY_ELEMS would have to be 1, I think.
There was a problem hiding this comment.
Well, this idea is based on a demonstration purpose rather than common sense for this use case. Because a composit key implementation is more complex than a single key implementation. 🙃
|
Finally added a suggested PR into the docs repo: CosmWasm/docs-deprecated-2025#254 cc @uint |
2 participants
Why?
Sometimes, it's useful to store a custom type as a key in a
Mapstorage structure. To do this, users need to implement proper serialization for such types.So I found it useful to add such an example with a reference implementation for a widely used
Denomenum that represents either a native token or a cw20 token.Scope:
Denom