How to run migration scripts for tenants

[TimoGlastra]

At what time and how do we trigger it? Probably easiest to do when a wallet is openend, but that can create quite some load when you want to use a wallet, so there should be a way to do it beforehand

[TimoGlastra]

if using multi-tenancy you can't update to 0.4.0 (yet). Same as with Node.JS and Postgres migration support being low, we may give that some extra attention in the 0.5.0 release. We should somehow loop over all tenants and update them. This is something we can do as part of the new module updates (so the tenatn module can provide the updates), but I'm thinking about how this will work when working with large scale deployments. My thinking is:

• We start looking at parallel change updates (https://martinfowler.com/bliki/ParallelChange.html), meaning we support both the old version and new version in parallel for a while
  • When a new verison is released, you update all agent(s) deployment to the latest version, which works with both the previous and the new storage version
  • It also supports a partially updated database (where storage is mixed)
  • You could have a separate process that updates the wallets, this would warrant the lowest downtime (if any downtime is needed at all).
    • To avoid issues we should be able to lock records that are being updated. This requires Askar and updates in AFJ to be able to lock records.
  • We should try to minimize breaking changes going forward. We have re-architectured quite a bit and I think we can start making the API more stable.
• We allow to update tenants one by one, and store which version a tenant is on in the TenantRecord

I think 0.5.0 could focus on scalability a bit more anyway, allowing the paginate queries instead of fetching all records in a getAll, etc..

[TimoGlastra]

Done