Non-serialisable representation of migrations but grants greater expressiveness

Scenario:

1) You changed some case classes and/or codecs 2) You want to see if deploying the code will work in some environment, i.e. will the data in that environment be decodable losslessly to the new schema 3) Therefore you need to take the data in the environment, apply any new migrations to it, and then decode/encode it with the new code/codecs. 4) This always requires the migrations & data be co-located.

The code here assumes you data will move to whereever the migrations are, i.e. that it's accessible, this may not be possible for some environments (prod, secure, disconnected, etc.)

If you can't move the data to the migrations you might be able to move the migrations to the data, but then the migrations need to be serializable, and thus cannot contain custom code. That approach is in jsondbc.migration.data