Anyone know how sqlite makes money?
Work on SQLite4 has concluded
21–30 of 161 posts
Re: Work on SQLite4 has concluded
#22Doubt still exists... Does this mean 'concluded' as in "We've finished polishing the pre production code and are close to releasing it" or 'concluded' as in "We have thrown our hands up in the air and won't be working on this thing any more to bring it to production" ??!!?? EDIT Seeing as I am getting slammed by downvotes, my comment here was simply pointing out that the headline I saw on HN could be read in multiple…
The answer you seek is in the link, in highlighted green text.
Yes, it is, but I also initially assumed that this was a successor to SQLite3. No, it didn't take long to correct that misunderstanding, but it would be nice if the title were clearer.
Re: Work on SQLite4 has concluded
#23Doubt still exists... Does this mean 'concluded' as in "We've finished polishing the pre production code and are close to releasing it" or 'concluded' as in "We have thrown our hands up in the air and won't be working on this thing any more to bring it to production" ??!!?? EDIT Seeing as I am getting slammed by downvotes, my comment here was simply pointing out that the headline I saw on HN could be read in multiple…
" Lessons learned from SQLite4 have been folded into SQLite3 which continues to be actively maintained and developed. This repository exists as an historical record. There are no plans at this time to resume development of SQLite4." Right there on the web page. Highlighted in green even.
Come on. Shaming helps nobody. I know I've missed seemingly obvious things before and am sure everyone else here has as well.
Re: Work on SQLite4 has concluded
#24instead of pretending to release a new version, it might be better to just call this fork sqlite-failed.
Re: Work on SQLite4 has concluded
#25The biggest thorn I found working with sqlite was the lack of ability to modify columns with ALTER TABLE which was a real pain. Doesn't look like this is fixed in sqlite4 though...
lack of window functions kill it's usefulness for me.
Re: Work on SQLite4 has concluded
#26For context, SQLite4 explored reimplementing SQLite using a key-value store on log-structured merge trees, like RocksDB and Cassandra. I'd be interested to hear why they stopped. Presumably reimplementing SQL on a KV store was seen as not worth it, when applications that are satisfied with an embedded KV store backend (which is much faster and simpler to write!) already have many options.
Everything I hear about SQLite3 always suggests that, essentially, it is considered "done". It does what it is supposed to do with great performance. There is nothing major left to do. If it doesn't meet your needs, pick a different SQL database.
Which, while a totally alien concept in the modern software world, is actually a pretty cool thought.
(I'm sure under the hood bugs are getting fixed and all)
Re: Work on SQLite4 has concluded
#27For context, SQLite4 explored reimplementing SQLite using a key-value store on log-structured merge trees, like RocksDB and Cassandra. I'd be interested to hear why they stopped. Presumably reimplementing SQL on a KV store was seen as not worth it, when applications that are satisfied with an embedded KV store backend (which is much faster and simpler to write!) already have many options.
Scaevolus, I recognise that name. #0x10c-dev on freenode? rmmh? skybot? I created a logsql.py plugin for skybot, it just logs to the DB instead of to text files. Is that something you'd be interested in merging back in?
Developer of some optimization mods for Minecraft, one of which became OptiFine.
Re: Work on SQLite4 has concluded
#28For context, SQLite4 explored reimplementing SQLite using a key-value store on log-structured merge trees, like RocksDB and Cassandra. I'd be interested to hear why they stopped. Presumably reimplementing SQL on a KV store was seen as not worth it, when applications that are satisfied with an embedded KV store backend (which is much faster and simpler to write!) already have many options.
Would have been a neat way to experiment around with putting a SQL front end on various KV interfaces. Redis or etcd, for example.
CockroachDB has a good blog post[0] that describes how they implemented SQL. (CockroachDB is a key-value store.)
[0] https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mappin...
Re: Work on SQLite4 has concluded
#29The biggest thorn I found working with sqlite was the lack of ability to modify columns with ALTER TABLE which was a real pain. Doesn't look like this is fixed in sqlite4 though...
Same here. Had to switch to dockerized mariadb for local tests, because migrations wouldn't work.
Wouldn't you want your tests to be run against the same DB family (and version) as production anyway?
Re: Work on SQLite4 has concluded
#30Richard Hipp has said that they have signed contracts to support SQLite3 for 35 years. SQLite4 is never going to happen.
What kind of companies sign 35 year support contracts?