The "immutable" design of iroha_data_model causes inconvenience

[0x009922]

This topic was raised many times before, and so I decided to make a dedicated issue for it.

Problems with decomposition

Given the immutability of the structures, it is impossible to decompose them in most cases. The only way to access them is to get immutable references. Explorer re-wraps everything in its own structures. It could be done either by lots of clones, or by lots of lifetimes. It seems a bit insane given that in the context of Explorer there is not point of holding original data model structures and making its reflections for api responses. It would be convenient to own and move internal data directly.

It could be workarounded with the transparent_api feature, but it is supposed to be for internal use only.

- soramitsu/iroha2-block-explorer-backend#44 (comment)

"Forgetting" to expose some getters

While using iroha_data_model crate without transparent_api feature, I repeatedly and very often stumble upon the same issue: some structure doesn't expose getters for its fields, for all or only some of them.

This happens because it is done manually in most cases and is not covered by some sort of static check for consistency.

Moreover, in CI iroha_data_model seems to always compile with transparent_api feature enabled, thus CI doesn't catch even internal possible inconsistencies. For example - #5049: iroha_genesis uses iroha_data_model without transparent_api feature enabled while accessing private fields. It works fine in Iroha repository, but doesn't work from the outside.

Such things are really minor to fix, but it is too much effort and time to open PRs for each of them. Example of such a PR: #4992

In a sense, I find this "forgetting" issue to be similar to the issue with errors: #4974. Errors are also mostly done manually and mostly never really tested.

Related data-model refactoring issues

• [suggestion] Eliminate AssetType inconsistencies #4087
• [suggestion] Genesis: change the Mint behaviour #4101
• [suggestion] Replace Grant/Revoke with Mint/Burn #3924
• Redundant identifiers in storage values #5034

[nxsaken]

On destructuring and transparent_api, can we have data model structs with private fields and a pair of (fn from_parts(...) -> Self, fn into_parts(self) -> ...) for going in and out of the data model context? Even with this, I think that data model types should provide methods instead of relying on something outside using their fields in a correct way. This seems to be related to data model anemia (leaking internals instead of providing the needed functionality through the types).

[mversic]

@nxsaken I think you mean such as described in #4360 ?