Open minesh-s-patel opened 1 year ago
@minesh-s-patel What do you see under "compatible changes"?
In your example, the new B
type is a subtype of the old one, which might seem like it will always be compatible. However, that's not really the case. Suppose the original model also contained the following function:
namespace model1.func
func Create_B:
inputs:
i int (1..1)
output:
result B (1..1)
set result->i: i
then adding the field j
to the B
type will make this function return invalid B
instances.
I see two possible ways of moving forwards.
The first and easiest one is to make a couple of rules about what is considered a "compatible change", and only to allow such changes. Examples would be:
The second and more general one is to allow incompatible changes, but also detect all places where the changes interfere so we can force the modeller to override those types/functions as well. For example, when changing the type of an attribute, you would be forced to override all functions using this attribute as well.
Note that in both cases this would also require major changes to our code generators.
Do you think the first option is enough for the use cases you have in mind, or are there cases that warrant the second option?
Problem:
The Digital Regulatory Reporting (DRR) model extends the common-domain-model. The DRR model may find an issue with the CDM and need to make a modification to a
type
orfunc
. At present, the only option we have is to fork the rosetta file in CDM and make the modification which is hard to maintain.It would be good to be able to overwrite some namespaces types.
Proposal:
Base namespace that is being used in downstream model:
Model utilising the
model1.base
, but modifyingmodel1.base -> B
If the new definition of
B
is incompatible with any part of the model, it is treated like an error. This will force the user to make compatible changes only.