3 ms·
I’ve worked in all those places (currently in the fully versioned model). We occasionally do a full reset using an export of the current schema as a new base a
by aidos 5y ago
I’ve worked in all those places (currently in the fully versioned model).
We occasionally do a full reset using an export of the current schema as a new base and then start versioning again from there. So there’s not really a good technical reason to stop people from getting a working runnable migration system going - other than social, as you say.
- KronisLV 5y ago> So there’s not really a good technical reason... One that i can think of is the application depending on some set of data being present in the system, which was added ages ago and that no one has any idea about across the hundreds of tables. Furthermore, you probably can't just do a full export/import of the initial state, because everyone having to download about 2 GB of data a large portion of which is auditing related information probably also isn't all that good. Well, that's more of a technical aspect that's caused by social factors, to be honest, but probably is a blocker nonetheless. Especially if you can't convince anyone to spend a week exploring the schema and setting up this baseline migration & data, when things currently "work well enough" and when the company doesn't give you a data storage solution to keep it at (e.g. NextCloud), doesn't let you use Git LFS or something like that, anyways...
- marcus_holmes 5y agothe data in your system is massively more important than the code. Not spending a week exploring and completely understanding your schema is going to hurt you in the long term.