Module module_version

Most of the CW* specs are focused on the public interfaces of the module. The Adapters used for ExecuteMsg or QueryMsg. However, when we wish to migrate or inspect smart module info, we need some form of smart module information embedded on state.

This is where ModuleData comes in. It specifies a special Item to be stored on disk by all contracts on instantiate.

ModuleInfo must be stored under the "module_info" key which translates to "636F6E74726163745F696E666F" in hex format. Since the state is well-defined, we do not need to support any “smart queries”. We do provide a helper to construct a “raw query” to read the ContractInfo of any CW2-compliant module.

Additionally, it’s worth noting that ModuleData is utilized by native abstract contracts.

For more information on this specification, please check out the README.

Structs

• ModuleData
  Represents metadata for abstract modules and abstract native contracts.
• ModuleDataResponse

Constants

• MODULE

Functions

• assert_contract_upgrade
  Assert that the new version is greater than the stored version.
• assert_cw_contract_upgrade
  Assert that the new version is greater than the stored version.
• migrate_module_data
  Migrate the module data to the new state. If there was no moduleData stored, it will be set to the given values with an empty dependency array. If the metadata is None, the old metadata will be kept. If the metadata is Some, the old metadata will be overwritten.
• query_module_data
  This will make a raw_query to another module to determine the current version it claims to be. This should not be trusted, but could be used as a quick filter if the other module exists and claims to be a cw20-base module for example. (Note: you usually want to require interfaces not implementations of the contracts you compose with, so be careful of overuse)
• set_module_data
  set_module_version should be used in instantiate to store the original version, and after a successful migrate to update it