Versioning Activities and Operators

This page describes what to do in order to correctly change the way to configure an activity or an operator: the goal of versioning is to automatize the conversion of configurations when you change the configuration format.

Ac/Op configuration:

Any activity or operator has:

• a configuration that is stored in the elements of the MongoDB collection activities and operators as data as an object.
• a configuration version number stored in the same elements as configVersion as an integer.

Modifying a configuration

You can change the configuration of an activity xyz in the file ac/ac-xyz/src/index.js or ac/ac-xyz/src/config.js. When you do so, all activities that where configured using the previous version will be broken, and the same goes for the operators. To avoid this, 2 modifications are in order:

Update the version of the configuration

Simply increment the field configVersion in ac/ac-xyz/src/index.js or op/op-xyz/src/index.js

Implement an upgrade function:

The file ac/ac-xyz/src/index.js or op/op-xyz/src/index.js export as default a field called upgradeFunctions. This field is an object containing the conversion functions. it has its type defined in frog-utils/src/types as upgradeFunctions?: { [version: string]: (Object) => Object } in ActivityPackageT. Its attribute called x let is a function that takes as input the configuration as the object data that has the format x-1 and return the configuration in the format x.

You only need to implement the upgrade function from the previous version to yours as if there is a need to convert a config version x-y to your format x, all functions from x-y+1 until x will be automatically chained.

There is an example in ac-quiz/src/upgradeFunctions.js. Upgrade functions are executed over all database content whenever Meteor is restarted, and also on all imported functions or graphs. Note that shareDB reactive data is not automatically upgraded, so if you change the format of this data, sessions in-progress might crash.