Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Work on SQLite4 has concluded

sqlite.org

Post reply on HN
Print view View original

11–20 of 161 posts

Re: Work on SQLite4 has concluded

#11

Post by labster »

cyberferret wrote: post #10
fgonzag wrote: post #9

Earlier quoted context omitted.

" 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.

Below the fold even, after about 1000 other words of text. Would be better if the title had used 'cancelled' or 'terminated' instead of 'concluded' to explain the situation at the outset?

It's a code revision, not an article. If you're a programmer the change is super obvious.

Re: Work on SQLite4 has concluded

#12

Post by tyingq »

Scaevolus wrote: post #3

For 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.

Re: Work on SQLite4 has concluded

#14

Post by nerfhammer »

tyingq wrote: post #12
Scaevolus wrote: post #3

For 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.

Fairly straightforward to make a mysql storage engine for it, e.g. https://github.com/AALEKH/ReEngine

Re: Work on SQLite4 has concluded

#16

Post by alphaalpha101 »

Scaevolus wrote: post #3

For 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?

Re: Work on SQLite4 has concluded

#18

Post by krylon »

assface wrote: post #13

Richard Hipp has said that they have signed contracts to support SQLite3 for 35 years. SQLite4 is never going to happen.

Look at it this way: SQLite3 is (more or less) slowly becoming SQLite4, except for the parts that did not work out.

It is not as shiny, but in the long run, you still get all the goodness. Nevermind the name / version number.

Re: Work on SQLite4 has concluded

#20

Post by kamac »

hoodoof wrote: post #15

The 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.
Post reply on HN