I mean, sometime along the way you’re going to have something that consumes the data (otherwise, why bother keeping it in the first place), and that something will have certain expectations about the way things are structured.
It will probably become a good idea then to have some clue as to what structure used to be at one point or the other, and for that you’d want to keep track as to what got added/removed and when.
If it’s a very early stage in the development, and you don’t expect any of the current data to survive to the final version, I guess that’s fine. But when you have an actual running product that has to keep running, dealing with the multiple versions of the data scheme is a pain, and dealing with the multiple untracked versions of the data scheme is a pain squared.
I use a lot of JSON columns w/ SQLite and find a programming language type is a great way to specify schema for such a column without having to write any migrations. No one has written a sternly worded comment at me on the internet yet for adding or removing fields from my struct types without writing a separate migration file.
Lots of use-cases for SQLite are not like Big Iron SQL Database Of Record where every change must be tracked because it's a shared stateful single point of failure and there's hell to pay for mistakes or confusion.
Not quite. We are saying that adding `not_available_before: 2026`, or similar, ‘right away’ is usually not a good thing; therefore anything that helps with doing that is not something we desire.
It should be a multistep process. Yes, it will waste time now, but it will save it in a long run.
