BluePenguinB
Convex Community6mo ago
17 replies
BluePenguin

First-class offline migrations

I realise that Convex's focus on online migrations is good policy for apps that run at scale.

As an pre-PMF company we just want to rapidly prototype and having to do multi-step actions for a new non-nullable field (1. add optional field, 2. migrate, 3. remove optionality) really kills our speed.

This approach also kills typesafety. I provide an example below

We'd love to be able to do offline-migrations that still keep type-safety & schema validation.

Example:

* Write migration
* Deploy convex
* Transaction start
* [Convex]: disable schema validation
* [Convex]: execute migration (this would be a non-typesafe step)
* [Convex]: validate new schema
* [Failed]: fail transaction & revert
* [Success]: enable schema validation
* Transaction end
* [Convex]: if success: deploy everything else
* [Convex] server online

Why does the current approach kill type safety?


Between step 2 (run migration) and step 3 (remove optionality) there is a non-trivial amount of time, because both require separate deployments and a code change.

Therefore the optionality is still present AFTER the migration and BEFORE the new schema.

This means any typescript verification will NOT catch
insert
s that leave the new document's value unset. Therefore there is a possibility of breaking the ability to execute step 3 during that time.

This to me breaks one of the big values of Convex; end-to-end type safety.

It leaves me leaving optionality everywhere and running run-time checks (opposed to deploy-time-checks) which is inherintly a non-TS approach.

If you got this far thanks for reading.
Was this page helpful?