Modules generally have business-related data structures. For example, module test-party has a business data table testParty, which contains several fields

After the module is compiled, deployed and released, the current data version of the module is recommended to be in a closed state. If module data architecture changed, an incremental data version is required. In this way, with the upgrade of the module, the data architecture inside the module will also be upgraded automatically and seamlessly

Definition of Data Version

Configure fileVersion as the current data version in the file package.json of the module

  1. 1{
  2. 2  "name": "egg-born-module-test-party",
  3. 3  "version": "2.1.43",
  4. 4  "eggBornModule": {
  5. 5    "fileVersion": 4
  6. 6  }
  7. 7}

Backend API Routes

The following API routes need to be implemented, which are automatically called by the system when upgrading the data version

  1. 1// version
  2. 2{ method: 'post', path: 'version/update', controller: version, middlewares: 'inner' },
  3. 3{ method: 'post', path: 'version/init', controller: version, middlewares: 'inner' },
  4. 4{ method: 'post', path: 'version/test', controller: version, middlewares: 'test' },
Name Description
middlewares: ‘inner’ indicates this API route only be allowed inner access
middlewares: ‘test’ indicates this API route only be allowed in the test environment
version/update Data architecture changes unrelated to multi-instance
version/init Data architecture changes related to multi-instance, such as initializing authorization for some built-in roles
version/test Only execute in the test environment for initializing unit-test related data, such as providing initial test data or initial role authorization for the subsequent unit-tests

Difference between version/update and version/init

  1. One EggBornJS service can support multiple instances, and the instances shares the same MySQL database architecture, but the data generated dynamically is isolated from each other
  2. version/update deals with data architecture changes that are not related to multi-instance, such as tables, views, store procedures and functions, etc.
  3. version/init deals with data changes that are related to multi-instance, such as function authorizations, menu authorizations and atom authorizations, etc.

Backend Logic

src/suite-vendor/test-party/modules/test-party/backend/src/service/version.js

  1. 1module.exports = app => {
  2. 2
  3. 3  class Version extends app.Service {
  4. 4
  5. 5    async update(options) {
  6. 6      if (options.version === 1) {
  7. 7        ...
  8. 8      }
  9. 9      // if current fileVersion=2
  10. 10      if (options.version === 2) {
  11. 11        ...
  12. 12      }
  13. 13    }
  14. 14
  15. 15    async init(options) {
  16. 16      if (options.version === 1) {
  17. 17        ...
  18. 18      }
  19. 19      // if current fileVersion=2
  20. 20      if (options.version === 2) {
  21. 21        ...
  22. 22      }
  23. 23    }
  24. 24
  25. 25    async test() {
  26. 26    }
  27. 27
  28. 28  }
  29. 29
  30. 30  return Version;
  31. 31};
  32. 32
Name Description
options.version It is only necessary to write corresponding change logic for different data versions of the module, and the system will automatically perform the corresponding codes according to the current data version