I agree with you. This kind of functionality is much better implemented in a third-party tool like sqlalchemy-migrate or alembic that OP mentions in the article.
I much rather a smaller sqlite library than one that is burdened with functionality you just don't use 99% of the time.
The benefit of making an "official" migration library for SQLite is probably outweighed by the opportunity cost of having it developed, tested and kept up-to-date.
This makes no sense. Who's more capable of keeping a solution for this developed, tested, and up-to-date, the core developers of the database or a third party that's probably hoping to achieve something other than a migration tool?
It's worth noting that it's not like rewriting the whole table is a solution to this that's unique to SQLite. MySQL's two main table types also do this in order to alter a table in certain (very common) ways. But they don't make you do it yourself, because it's deceptively difficult to do it right.
Look at the issue a different way. What functionality needs to be removed from SQLite in order to add more comprehensive alter table? SQLite is defined by being "lite" and that involves a lot of saying "no". You can use other database solutions.
SQLite is also public domain. You can cause this code to be written and have complete freedom to redistribute/keep private as you see fit.
So what is actually being demanded here is that the SQLite core developers spend their time on the feature. SQLite used to have no table altering functionality at all. The ability to append a column (which had few technical risks or ambiguity) was paid for by AOL.
Yep, and I said in the article that I'd be happy to pay for adding other ALTER TABLE methods... if someone ran a funding campaign, I'd donate quite a bit of money. I still suspect that if such a campagign was run, we'd see a good set of money come in from the community for it.
The problem though is that Alembic doesn't want to engineer itself around implementing the tooling because it's so painful (and the author of that tool is himself asking for this kind of alter table support) and sqlalchemy-migrate breaks all the time. And sqlalchemy-migrate breaks all the time, and when I used South and django-migrations (granted, that was years ago), those also broke all the time too. The external migrations path isn't working.
So write and apply such modification scripts manually. It's not difficult, and you can tailor it to your table's unique or unusual properties, as needed.
I've seen too many people waste far too much time and effort with automated migration systems, for what amounts to very little saving even in the cases where it does work well.
> This kind of functionality is much better implemented in a third-party tool like sqlalchemy-migrate or alembic that OP mentions in the article.
Yes because now every SQL migration library of every language has its own partial bug-ridden of a full alter table for sqlite. That does sound so much better than having a single implementation in sqlite itself (wait no, it does not even remotely).
But now every user of SQLite needs to deal with a library that's larger, and includes non-critical functionality that goes unused.
The whole point of using SQLite in the first place is to avoid such overhead, knowing full well that some non-essential functionality is being lost as part of this tradeoff.
I think it's far more important to keep SQLite small and nimble for the many users who are facing constraints beyond their control (imposed by limited hardware resources, for instance), rather than bloating it for the sake of a small number of users who are unwilling (or too lazy?) to write proper manual migration scripts now and then.
I much rather a smaller sqlite library than one that is burdened with functionality you just don't use 99% of the time.
The benefit of making an "official" migration library for SQLite is probably outweighed by the opportunity cost of having it developed, tested and kept up-to-date.