search

lavab / web

AngularJS web client of Lavaboom's email service
https://mail.lavaboom.com
38 stars 21 forks source link

Migration scripts support #849

Open let4be opened 9 years ago

let4be commented 9 years ago

There are situations when we want to upgrade format of some internal data structures inside web, currently it's handled in a hacky way

  1. somewhere there is version support per structure
  2. somewhere there is code than can simply handle both formats

I suggest to implement so called migration scripts that will be distributed as a separate angular.js module and loaded dynamically if there is such need.

step-by-step how it would work:

  1. add migration field to manifest.json example: migration: ["0.4.5"] states that update to 0.4.5 requires run of the appropriate migration script
  2. store current version of data structures inside user.settings example: user.settings={dataVersion: "0.4.4"} states that current internal data structures are compatible with all versions including 0.4.4 but are not compatible with anything further(i.e. "0.4.5" has introduces breaking changes)
  3. when application loads it checks current version, version stored inside user.settings and manifest.migration array if it find that in order to use current version we need to run a migration script(or a sequence of them) it downloads angular.js module with migration scripts and run all required scripts if everything went smoothly it updates user.settings.dataVersion to the current version and continues application loading

This would allow to keep code clean and tidy without ugly hacks to support multiple formats, once data structures have been updated using migration script we no longer need use hacky code to support weird and conflicting data formats across different versions.

For example recently I needed to update contacts structure as we removed hidden contacts concept and replaced them with regular contacts that user can delete/name/edit. Here it would be extremely useful i.e. new application can't use old format but old contacts are stored using old format so I had to modify code to support both

I find this more suitable approach instead of version each data structure separately - no need to support a ton of old outdated formats

cc @andreis @pzduniak

let4be commented 9 years ago

another use case: let's suppose(there was such situation in the past) there was a tremendous bug in "0.4.1" and all emails user has sent - cannot be read by recipients, but there are some internal data structures that would help to resend those emails thus fixing this issue

we could make migration script that states - run me when we upgrade to anything >= 0.4.1 and I will fix the shit

let4be commented 9 years ago

one side thing: as we store most of our data in encrypted format such stuff can be performed only client-side.