Maintenance of customer's model

Hi Askar,
"Script Aspects" are what you are looking for. On a language, just right-click to open the context menu, choose New/Scripts Aspect. There you can create "Language Migration Scripts"

You may have a look at https://github.com/jensnerche/mps-options. There I have a short demo how to handle language evolution regarding to customer models. I factored it out of a real life project where it worked fine. The demo (a tiny feature model language) consists some other stuff like custom menus, but let's focus on the tiny demo language called "instance". In the sandbox is a solution called "Jens" which uses this language to configure a car based on the "Car" model in the same sandbox. The ProductInstance concept has a Customer concept as child, which only has the name as property. The first iteration of the language had the customer as "exactly one" cardinality. Now one could think of removing the Customer concept and put the name as only attribute directly into the ProductInstance (or the other way around, the reversed script is also included in the demo). First thing to do is to make the customer optional, so change the cardinality to 0..1 and to add the name as an attribute to ProductInstance (already done in the demo, ProductInstance implements INamedConcept). Then create a Language Migration Script, I named it IncludeCustomerNameIntoProductInstance. It's really short, as you can see, and self explaining. It appears in the Tools/Scripts/Enhancements menu. You can compare the AST before and after the run. I think you get the idea what is happening through the migration.
Now you have the legacy customer in your language, but you have to keep it until the next iteration of your language, because otherwise the migration script could not work.

To the other question of how to store customer's models - normally we at Kontext E store the models in MPS, but in some cases also as external (generated) text for some project internal reason. In the latter case we had to write an importer to read the text and re-create the models. Both works well, for one upcoming project we think about storing the data in a graph database because of the domain nature and interacting with other tools. I think it really depends on your project settings. MPS is able to use a VCS, so a model can be as save as other source code.

So have fun with metaprogramming! ;)

Jens

Jens, thanks for your complete answer! I'll give it a try!

If I get it right, in this example you operate on a new language in script. And what if I need to map nodes of deprecated concept from old version of language, that was removed from a new version of language?

In the example, the Customer concept is deprecated and should be removed. So all data (here the name only) has to be transfered. But in the new version of the languange, the deprecated concept of the Customer is still included. It can only be removed in the version _after_ the new one, if all transformations were done and the concept isn't used anymore. Otherwise you are not able to create a transformation script (or a generator for m2m transformation) - and all existing models would be invalid. MPS needs always a correct AST, therefore as the first step the cardinality of Customer was changed from 1 to 0..1 to make it optional.

Ok, now I get that. And in this case language enginer should preserve deprecated concepts, deprecated node relationship and deprecated properties until last known customer moves on new version. But I think this approach doesn't fully use an advantage of projectional storage. Shouldn't I be able to drop support of deprecated concepts with the next language version? I think it's possible to keep your language clear and in the same time preserve possibility for model version migration, but wonder if there are any special concepts (i.e. MigrationRule(Language1 -> Lanugage2)) or model types (i.e. migration model) already available.

Created an issue: MPS-17487 Model and language versioning support

This is a known issue for a long time, but we still have no time to implement it. Moreover, I have some ideas on how to write refactorings that will be usable even in case when refactored node was removed, so that you no longer need to handle old concepts for one additional version of your language. Maybe we'll implement this after 3.0.

If someone would like take a look at it and possibly to implement and contribute to MPS, I could share my vision of a new refactoring framework. It's quite simple and just needs some time to implement, everything is core - independent except model versioning.

To do this, is it required to have MPS git project on a local machine or, moreover, a knowing of internal MPS API? :)

I downloaded project from github, but all libraries in project absent. Where can I borrow these?

All libs should be there. The workflow with the sources is as follows:

1. open the project in IntelliJ IDEA 12
   
2. Rebuild the project
   
3. Run the MPSLauncher run configuration to start MPS
   
4. open MPS in the now running MPS instance

Did it help?

IMO all except model-version control system (which is not really necessary in the beginning) could be done on MPS build, even without contributing to MPS core.
The only thing you should know is SNode.getId(), SModel.getId() methods and you should understand how MPS node references work.
In 3.0, all these things will be stated as OpenAPI.

Now we don't store Idea platform libs in repository. Instead, we use Apache Ivy to get them. Ivy is executed before making project. So, as Vaclav said, you should just "make" MPS and you'll get required libs.

Followed by your instructions I'm now on the way to get what I needed. The next showstopper is an error that arises when executing Ivy script (running from build folder, I re-enabled logging):

//
// ~100500 lines of what we have already downloaded
//
BUILD FAILED
c:\Project\MPS-master\build\build.xml:31: The following error occurred while executing this line:
c:\Project\MPS-master\build\mpsDistribution.xml:33: c:\Project\MPS-master\help does not exist.

help folder really doesn't exist.

Sorry for such a long delay. Now I'm tuned.
So, after commenting out lines related to help folder, I'm finally got Ivy build file executed successfully.
Vaclav, thank you for instructions! Currently, I have MPS project of MPS opened right in front of me.
Mihail, please suggest me, where should I dig and what are your ideas on topic?