Neither I nor the SQLite team think that SQLite is the solution to everyone's database use. As they say it is a good alternative to fopen: http://www.sqlite.org/whentouse.html - it is not a project goal to be a complete SQL implementation or to be a drop in replacement for MySQL/Postgres/Oracle etc
SQLite's manifest typing is a complication for ALTER TABLE that doesn't affect other databases.
On the ORM side, my point was that layers of abstraction and indirection will make things harder. Is your statement that they would have to have SQLite specific code the only reason why it isn't done, or is there something else considered hard?
While it is true your voice isn't heard, enough people do post to sqlite-users to get some idea of what the various issues are and a rough idea of their popularity. For example a far more common issue is that SQLite does not work well if you use a networked filesystem (you will eventually get corruption).
Timeliness is a practical issue. ALTER TABLE can't be used until it is available. The way the SQLite developers consider best practise is you embed the SQLite library statically inside your app and you write specifically to SQLite: http://www.sqlite.org/amalgamation.html
There are no legal or technical reasons preventing anyone to cause this to be implemented separately from the SQLite core. Wanting it to be part of the core is very different.
You seem to have an underlying assumption of zero sum games or SQLite being in some competition with all other database engines. It isn't. It doesn't lose by developers using MySQL or MongoDB. Heck I use MongoDB far more than I use SQLite. Developers who need comprehensive ALTER TABLE support and find the copy table with modifications approach too onerous are far outside of SQLite's sweet spot. That is ok.
SQLite's manifest typing is a complication for ALTER TABLE that doesn't affect other databases.
On the ORM side, my point was that layers of abstraction and indirection will make things harder. Is your statement that they would have to have SQLite specific code the only reason why it isn't done, or is there something else considered hard?
While it is true your voice isn't heard, enough people do post to sqlite-users to get some idea of what the various issues are and a rough idea of their popularity. For example a far more common issue is that SQLite does not work well if you use a networked filesystem (you will eventually get corruption).
Timeliness is a practical issue. ALTER TABLE can't be used until it is available. The way the SQLite developers consider best practise is you embed the SQLite library statically inside your app and you write specifically to SQLite: http://www.sqlite.org/amalgamation.html
There are no legal or technical reasons preventing anyone to cause this to be implemented separately from the SQLite core. Wanting it to be part of the core is very different.
You seem to have an underlying assumption of zero sum games or SQLite being in some competition with all other database engines. It isn't. It doesn't lose by developers using MySQL or MongoDB. Heck I use MongoDB far more than I use SQLite. Developers who need comprehensive ALTER TABLE support and find the copy table with modifications approach too onerous are far outside of SQLite's sweet spot. That is ok.