Ability to save a ModelManager to a set of CTO files

[accordproject]

Ability to save a ModelManager to a set of CTO files

[jeromesimeon]

Some random thoughts:

1. One of the benefit of using the metamodel is that indeed this allows to decouple editing from validation
2. If we have a metamodel to ModelManager loading method, we can get rid of the AST in the model manager
3. Using the metamodel in that way seems generally aligned with the direction of "functional Concerto" which primarily manipulates JSON objects.

[jeromesimeon]

A strategy toward this goal could possibly make use of the new metamodel (i.e., use updates on the metamodel, generate CTO or model manager from them).

[dselman]

@jeromesimeon can this be closed as "implemented" now?

[jeromesimeon]

@dselman Not really yet if we stick to the letter of the issue.

Two reasons:

1. For model managers obtained from cto files: Currently you can take an individual model file and get the metamodel instance for it. You can also generate a .cto file from that metamodel instance. What you cannot do yet is generate a set of .cto file from all the ModelFiles in the MetaModel.
2. For model managers obtained programmatically (not sure if anyone actually uses that). You cannot get the metamodel at all, since the metamodel generation uses the parser AST at the moment. So it only works if you have parsed a cto file in the first place. I think this would need to be addressed for the update scenario.

[dselman]

I think I get it.

For (1) this doesn't sound like too much work, is it? Loop over a set of meta models and convert each to a CTO file with the correct name in a directory (or in memory) using FileWriter. I can take a stab at that, if useful.

For (2), we probably need a discussion and a design. In particular how we deal with referential integrity errors that are introduced during editing. My gut feeling is that perhaps we start by supporting people editing the meta model JSON and then internally convert it to CTOs (first level of validation) followed by parsing the CTOs and bringing it back into memory as a new ModelManager (second level of validation, to check references are valid). It's a bit convoluted and inefficient but probably less invasive on the existing code. Happy to brainstorm and talk that over in person!

[jeromesimeon]

I think I get it.

For (1) this doesn't sound like too much work, is it? Loop over a set of meta models and convert each to a CTO file with the correct name in a directory (or in memory) using FileWriter. I can take a stab at that, if useful.

yes that's trivial, except maybe for the file generation. would be best to create a ./output directory as we do for other generations maybe.

For (2), we probably need a discussion and a design. In particular how we deal with referential integrity errors that are introduced during editing. My gut feeling is that perhaps we start by supporting people editing the meta model JSON and then internally convert it to CTOs (first level of validation) followed by parsing the CTOs and bringing it back into memory as a new ModelManager (second level of validation, to check references are valid). It's a bit convoluted and inefficient but probably less invasive on the existing code. Happy to brainstorm and talk that over in person!

agreeing completely. I think the bigger / harder question is what is the update API and what does it operate over (e.g., directly on model manager with CTO generation? or directly on metamodel instance with model manager generation?). Maybe I like the latter as you suggest, but I haven't spent much time thinking about this yet and it needs some design / review.

[dselman]

@jeromesimeon your recent PRs make good progress towards closing this. 👍

[mttrbrts]

@dselman can this be closed now?

[jeromesimeon]

@dselman can this be closed now?

I think all the foundations for doing this are in place. It would have to be double checked and also maybe some proper API for this should be discussed, which would allow to facilitate that use case, and document how to do it.