Project

General

Profile

Actions

Versioning of configurations (related to Carbon Benefit)

Overview of affected areas

  • Caching
  • Migrating data
  • New configuration: diff or copy?
  • API changes
  • Naming issues within code
  • Summary

Caching

The configuration objects ('empty paper questionnaire') is stored in memcache and the (uwsgi) process. The latter is a workaround, as serializing the object from memcache in python takes approx. 3 seconds. Therefore, the serialized objects from memcached are stored in the uwsgi process as 'last recently used' objects. As the uwsgi processes have an upper limit of consumed RAM and are restarted after the limit is reached, more configs = more trouble. As of now there are about 500 cache misses per day.

Decision:
Split configuration caching into sections. Try this asap, with A/B testing (cde staff).
This is just another 'plaster', but a refactor of the whole configuration object would be too time consuming.

Estimate:
?

Migrating data
How can the stored contents of a questionnaire be moved to a new version of the configuration?

Decision:
Custom 'migration' page, displaying only changing fields. Data from the 'old' configuration on the left; new (empty) fields on the right (or something like that...).

Estimate:
1 - 2w; only feasible with 'diff' for new configurations.

New configuration: diff or copy?
A configuration is a json object, which is loaded into the database. A new version of the configuration could be a copy of the whole object, or the 'differences' only. While a copy is cheaper in the short term, only storing the diff is the preferred option in the long run.

Decision:
'diff'

Estimate:

API changes
When data is migrated from configuration v1 to v2, the structure of the data on display on the API detail view changes. This is unexpected behaviour for the consumers of the API, and should be avoided. In order to display 'stable' structure of the data, a request to a 'stale' questionnaire should return a 404 / 302 (not found/redirect). (more discussion to follow here).

Decision:
New version of API (v3), where the configuration is a required URL parameter.

Naming issues within code
'Approach' and 'technology' are not used as a name for a configuration, but also as variables and so on. Rather technical, but the code (incl. tests) need updates.

Decision: required

Estimate:

Summary
'Switch' loading of data for different configuration versions, incl. tests

Decision: required

Estimate:

Updated by Sebastian Manger almost 7 years ago · 1 revisions