finos / rune-dsl

The project containing the Rune DSL grammar and default code generators
Apache License 2.0
26 stars 30 forks source link

Ability to overwrite a root element from an extended model #516

Open minesh-s-patel opened 1 year ago

minesh-s-patel commented 1 year ago

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 or func. 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:

namespace model1.base

type A:
   b B (1..1)

type B:
   i number (1..1)

Model utilising the model1.base, but modifying model1.base -> B

namespace model2.stuff

func calcB:
   input: A a (1..1)
   output: result number (1..1)

  set output: a -> b -> i + a -> b -> j

namespace override model1.base {

type B:
   i number (1..1)
   j number (1..1)
}

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.

SimonCockx commented 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?