When the shape of the DomeinFile changes

What is the problem?

Development of the PDR may consist of changing the representation of compiled Arc source files (the so-called DomeinFile). When this happens, all models must be recompiled to a DomeinFile before they can be read again by the PDR. DomeinFiles reside in Repositories, but are also copied to a local installation. We describe how to recompile both.

Recompiling the copies of DomeinFiles in an installation

As InPlace (built on the PDR) needs locally stored DomeinFiles files to function, we must recompile these files before the PDR starts. However, the compiler is part of the PDR. Clearly, this is a catch-22 situation. To solve it, we have an extra mode of using the PDR. This can be accessed by adding a query string to the URL where MyContexts resides:

https://mycontexts.com/?recompilelocalmodels=true

As of the time of writing, no success or failure message is conveyed back to the end user. However, by opening the browser console, one can inspect the trace of the recompilation. If a model did not compile well, this is shown on the console.

Alas, a single failure results in an installation being unusable.

The importance of being up to date

An assumption underlying this process of recompilation is that the locally installed version of DomeinFiles are correct with respect to the PDR prior to the update that introduced a new shape for the DomeinFile. In other words, it should be possible to recompile the models prior to the update (and then obtain exactly the same DomeinFiles, of course).

As a corollary, changes to the PDR that include changes to the shape of the DomeinFile must not also introduce other changes that require a revision (i.e. a change to PL source code) of models. This is obvious: such a change would require an adaptation of the model source text, which requires the new PDR to compile, but locally only the previous versions of the models are available because otherwise the (old) PDR could not use them!

Would an automatic update prior to recompilation not be the solution, instead of locally recompiling? It would, but it can only work if the Repositories have been updated first - that is, the patches must be available. And that requires at least a single installation from which the developer can patch the models, but that brings us back to the original problem: of recompiling models in an installation before the models in the repository have been patched.

In other words, the safe strategy is to include DomeinFile shape changes in a new PDR version that has no other changes (at least not changes that require a revision of models).

Consequently, an installation should be up to date before attempting to recompile local DomeinFiles. As patches are installed automatically, this is no more difficult than activating MyContexts periodically.

Note
When we control updates of the PDR, in the sense that we can decide not to retrieve a new version immediately, we can add a check to see if any patches must be installed and do so automatically before downloading the new PDR and attempting to recompile.

Recompiling the original DomeinFiles in a Repository

The CouchdbManagement model provides an action on the external role of a Repository, CompileRepositoryModels, that compiles the version of each model that is installed when a user adds it to her installation. This is the version that is in the property VersionToInstall.

This process is similar to that of compiling local copies in the sense that only actual runtime errors are reported back to the end user. However, the console displays information per model of the recompilation process.

Obviously, this action can only be performed from within MyContexts and thus only in an installation whose models have been recompiled before.

Automatic local recompilation of models

Note
We aim to achieve the following situation. It is not yet so!

When a new PDR version includes a change to the DomeinFile shape, it causes an installation to recompile its models automatically.