Support multiple data models in the same process task

[olemartinorg]

Description

We should start supporting multiple data models. Currently we only support one, and the logic is as follows:

• If using layout-sets (or if stateless, as stateless apps require layout-sets), we use the data type defined for the current layout-set (in v4 we also make sure that data type is registered in applicationmetadata)
• Otherwise, pick the first data type in applicationmetadata with a classRef and a taskId matching the current task ID.

In the future we should support multiple data models. That would have to include:

• Supporting an array (or object mapping) of data models in layout-sets, not just one
• Support in Studio for binding components to any of multiple data models
• A mechanism for selecting which data model each component should bind to. Either by explicitly choosing the data model per binding, or by automatically selecting the matching data model using schema lookups.

Additional Information

• Experiment: Storing the data model in a Context #1175
• Removing support for non-layoutset apps #1485
• Dynamic options does not work as expected with apps having two different datamodels #151 (maybe not relevant?)

[bjosttveit]

Some thoughts on this:

• I think its probably best to explicitly choose the data model when binding a component. Otherwise there are potential pit-falls if multiple data-models have fields with the same paths. I don't think we should impose a restriction of uniqueness to all data-model paths between all data models in the same step as this will be a headache for developers. This would probably be a breaking change, but it should be fixable with an upgrade script at least in data model bindings and expressions. For custom code, I am not sure how this will affect existing logic, but I don't think this choice will make a difference here anyway.
• Schema validation:
  Currently when validating against the data model schema, we validate the whole thing and each node picks out errors that have a matching data path to one of its data model bindings. This is rather inefficient for single field / few field validation, and would get even worse when having to validate x number of data models as well for large apps. There is a better way however. It is possible to specify a path in the schema to validate the data against, and that way, we can validate a subset of the form data against a subset of the schema, meaning we could validate fields individually which means we can choose to validate only the fields that have changed instead of everything all of the time. To do this however, we need to know the path in the schema that applies to a given data path. Luckily for us, the schema traversal code allowing us to see the schema for a given binding can likely easily be extended to also give you the path. What i'm thinking is that this information should be stored in the node item or something, so it only needs to be computed when the node is initialized.

[olemartinorg]

I think its probably best to explicitly choose the data model when binding a component. Otherwise there are potential pit-falls if multiple data-models have fields with the same paths. I don't think we should impose a restriction of uniqueness to all data-model paths between all data models in the same step as this will be a headache for developers.

Yes, me and @RonnyB71 discussed the same thing just now. I've been thinking that it's the quickest way to something that works, and configuration-wise it would be compatible with all existing apps (that only use one data model). I've always thought that if two (or more) data models have the same path, we need to disable the component and produce an error in some way so that the app developer knows they need to specify the data model to use.

But at the same time, if every binding was explicit about which data model to use (along with all text resources with variables, and all expressions that are doing lookups in the data model), and if locking each data element is added as an optional system task in the BPMN process (and pointing to which data type(s) to lock), we could remove the configuration options tying every data model to a specific process task (in both layout-sets.json and applicationmetadata). I'm not sure we'll get there in time for v4, though - so maybe v5? 🤔

Schema validation

Agree 💯! A very good suggestion! Let each node handle their own validations, and call on them to provide changes once they happen. This might depend on #1182 to be implemented first, in order to make the whole node tree a bit more stable (right now all node object are garbage collected and re-created much too often).

[olemartinorg]

A very relevant discussion regarding the specifics in this issue, including pros/cons of different approaches:

• https://altinndevops.slack.com/archives/C045EB3JA9X/p1699534481187189

[olemartinorg]

Removing fe-v4 label, as it's not critical for that release, and something we're planning to start working on right after. Tagging @RonnyB71 for notification.