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

91–100 of 161 posts

Re: Work on SQLite4 has concluded

#91

Post by chungy »

delinka wrote: post #52
foxylad wrote: post #36

Earlier quoted context omitted.

SQLite is used for small and embedded systems, which (if successful) can have very long lifetimes. If you were building something like an ATM for instance, you would be very sensible to sign a 35-year support contract for a crucial part of your system.

Have you seen an ATM? They're running Windows & SQL Server now. Microsoft isn't offering 35yr support contracts for Windows. This is only partially sarcastic.

Microsoft has nowhere near the quality, security and bug-fix track record, documentation coverage, nor testsuite coverage that SQLite offers. There's simply no way they can possibly provide such support.

Re: Work on SQLite4 has concluded

#92

Post by kijin »

mcbits wrote: post #86
kijin wrote: post #66

Earlier quoted context omitted.

Hwaci is a U.S. company, and the U.S. recognizes public domain. Therefore, no contributor can sue Hwaci in the U.S. for selling SQLite licenses.

I guess the question is what prevents those contributors from suing the licensee (or even Hwaci) in the country that doesn't recognize public domain? I assume we'll never find out because contributors obviously don't intend to sue anyone if they release their code to the public domain, but it's strange that a company would be comfortable buying a possibly illegitimate license when they're uncomfortable with a public…

I guess most companies that buy from Hwaci are more concerned about long-term support than about this public domain thingy, and "yes, we obtained a license" is just another box they need to check. $6K to check a box is pocket change to these companies anyway.

Besides, most countries in the developed world have some notion of giving away one's copyright (not moral rights, which can't be given away) so it might not be as much of a problem.

Re: Work on SQLite4 has concluded

#93

Post by malkia »

sametmax wrote: post #87
ianamartin wrote: post #65

Earlier quoted context omitted.

Well, obviously they should rewrite it in Rust.

Although i get the joke, it would be a fun and interesting experiment wouldn't it ? Espacially since the sqlite test suite is so exhaustive.

There is a version rewritten in C#, back in the day - not sure how up to date is:

https://www.infoq.com/news/2009/08/Porting-SQLite-to-.NET-in...

Re: Work on SQLite4 has concluded

#94

Post by petre »

X86BSD wrote: post #61
makmanalp wrote: post #56

Earlier quoted context omitted.

I got lucky! It was a class event, and he's known to speak at databases / data systems classes. He's a very fun (and opinionated!) speaker. > The in-memory tree is an append-only red-black tree structure used to stage user data that has not yet flushed into the database file by the system. Hmm, ok, so this contradicts my assumption. Actually, now that I think about it, other LSMs like rocksdb / leveldb work like this…

I just want to hijack this thread to say hipps other creation Fossil SCM is a great SCM. Better than git imo. Everyone should check it out.

We've been using it for the last 3/4 years. It's great and really user friendly, with integrated help and a web interface - everything in a single binary. The trouble with it is that it gets slower once you have a lot of history and many files. I don't know if you can use it for huge things like the Linux kernel or the FreeBSD ports tree. I once tried to import the ports tree into fossil and gave up after 2G and an hour. It will import anything that can do git fast-export. Now it also imports svn dumps as well. Fossil is a very good replacement for SVN. You can set up a central repo where everyone syncs on commit and update.

Re: Work on SQLite4 has concluded

#95

Post by malkia »

the_common_man wrote: post #17

Anyone know how sqlite makes money?

Possibly through their testing package (which is proprietary)

https://www.sqlite.org/testing.html

"The TH3 test harness is a set of proprietary tests, written in C that provide 100% branch test coverage (and 100% MC/DC test coverage) to the core SQLite library. The TH3 tests are designed to run on embedded and specialized platforms that would not easily support TCL or other workstation services. TH3 tests use only the published SQLite interfaces. TH3 consists of about 57.3 MB or 782.3 KSLOC of C code implementing 42213 distinct test cases. TH3 tests are heavily parameterized, though, so a full-coverage test runs about 1.7 million different test instances. The cases that provide 100% branch test coverage constitute a subset of the total TH3 test suite. A soak test prior to release does hundreds of millions of tests. Additional information on TH3 is available separately."

https://www.sqlite.org/th3.html

"TH3 License

SQLite itself is in the public domain and can be used for any purpose. But TH3 is proprietary and requires a license.

Even though open-source users do not have direct access to TH3, all users of SQLite benefit from TH3 indirectly since each version of SQLite is validated running TH3 on multiple platforms (Linux, Windows, WinRT, Mac, OpenBSD) prior to release. So anyone using an official release of SQLite can deploy their application with the confidence of knowing that it has been tested using TH3. They simply cannot rerun those tests themselves without purchasing a TH3 license."

Re: Work on SQLite4 has concluded

#96

Post by electrum »

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.

Presto has connectors for various types of non-SQL databases including Redis: https://prestodb.io/docs/current/connector/redis.html

Presto is a distributed SQL query engine for big data, so basically the complete opposite of SQLite, though it often gets used in federation scenarios, as does SQLite.

An interesting anecdote is that the team working on what would become osquery (https://osquery.io/) asked if they could reuse the SQL parser from Presto. We get that question a lot, and after explaining that the parser is the easy part (semantic analysis and execution is the real work), I determined that what they really wanted were SQLite virtual tables: https://sqlite.org/vtab.html (and those worked out great for them)

Re: Work on SQLite4 has concluded

#97

Post by RainaRelanah »

petre wrote: post #94
X86BSD wrote: post #61

Earlier quoted context omitted.

I just want to hijack this thread to say hipps other creation Fossil SCM is a great SCM. Better than git imo. Everyone should check it out.

We've been using it for the last 3/4 years. It's great and really user friendly, with integrated help and a web interface - everything in a single binary. The trouble with it is that it gets slower once you have a lot of history and many files. I don't know if you can use it for huge things like the Linux kernel or the FreeBSD ports tree. I once tried to import the ports tree into fossil and gave up after 2G and an h…

To be fair, Fossil's intended use case is the exact opposite of the Linux kernel. See 3.3 and 3.4 of the fossil vs git page[0].

[0] https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...

Re: Work on SQLite4 has concluded

#98

Post by xelxebar »

atombender wrote: post #77
exikyut wrote: post #51

Earlier quoted context omitted.

HN, stop being so monumentally stupid. This is a genuine question, and one that I had too. (To clarify, this is directed at all the downvoters, not the commentator I'm replying to.)

I didn't downvote, but I don't think it's too much to ask for commenters to read the linked web site carefully before they jump in with a comment. The answer is literally in the link.

It's not too much to ask. A person overlooked a thing once. Heck, I overlooked it too because on my phone the green text was so incredibly small I coudln't read it.

I don' think it's too much to ask for commenters to have a little charity.

Re: Work on SQLite4 has concluded

#99

Post by ZenoArrow »

chungy wrote: post #91
delinka wrote: post #52

Earlier quoted context omitted.

Have you seen an ATM? They're running Windows & SQL Server now. Microsoft isn't offering 35yr support contracts for Windows. This is only partially sarcastic.

Microsoft has nowhere near the quality, security and bug-fix track record, documentation coverage, nor testsuite coverage that SQLite offers. There's simply no way they can possibly provide such support.

There are products that Microsoft offers long support contracts for. To give an example, EOL for XP Embedded is in April 2019, which means XP in all its forms would've been supported for about 18 years.

Re: Work on SQLite4 has concluded

#100

Post by dotancohen »

ianamartin wrote: post #65
sliverstorm wrote: post #26

Earlier quoted context omitted.

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)

Well, obviously they should rewrite it in Rust.

Actually having an alternative implemention would be terrific.

Look how Open Office development charged after the introduction of Go OO, or MySQL after MariaDB, or more generally the entire smartphone market after the introduction of the iPhone. Competition is good.

That said, Dr. Hipp is known to be passionate about SQLite. In my previous examples the software was pretty much neglected before the competition came, which is certainly not the case with SQLite.

Post reply on HN