H
hutcj
Guest
I see - so even though you could produce the current full df by applying all the migration bundles in order from start to finish, it is still reasonable to actually store the full df in parallel in that same repo for its own purposes such as spinning up new test environments and running analytics? Repository hierarchy (could also be further organized by database name at the root level?): /schema - contains full df's /migrations - contains a folder for each delta, which in turn holds all the df & p files needed for that delta /data - contains d files with sample data for the current iteration For example: /db1/schema/db1.df /db1/migrations/delta001/ /db1/migrations/delta002/ /db1/data/ /db2/schema/db2.df /db2/migrations/delta001/ /db2/data/ etc. Or should all the d files be inside their corresponding deltas so that all versions of the data are available concurrently without having to checkout a previous version of the repository?
Continue reading...
Continue reading...