121–130 of 238 posts
Given the code quality and rigid testing, SQLite is probably the last project that should be rewritten. It'd be great to see all other C code rewritten first!
A side topic: is there a nice big extensive free test suite for sql, for people interested in making toy databases to use?
They aren’t fully open source but are free to use, including use with open source software. They may be a bit on the complex side though.
Like a node editor or spreadsheet? It needs to be suitable for general public
Earlier quoted context omitted.
That's fully in line with what they're announcing here. It's the announcement of a new project that has passed the prototyping stage, but one that has not reached the 1.0 stage.
And it never will The first 90% is easy, it's the second 90% that is very hard.
In case anyone else was wondering, SQLite is about 156k lines of code with 92,000k lines of test code.
The license is "Copyright 2024 the Limbo authors". How is that possible if Limbo is based on a rewrite? Do they claim a clean room implementation? It seems wise of SQLite to close down their test suite. That's a great idea I wish I had heard about earlier.
SQLite is in the public domain. It is perfectly legal to create a derivative works from a public domain project and license it however you want. It's not cool and kind of a dick move to put it under a more restrictive license, but it's legal.
A side topic: is there a nice big extensive free test suite for sql, for people interested in making toy databases to use?
Earlier quoted context omitted.
So a hard fork?
What is meant by a 'hard fork'? Are there different kinds of forks?
(In this case, since it's a rewrite in Rust, it's not actually a fork at all, I think)
Earlier quoted context omitted.
An SQLite fork will have a hard time being compelling enough to draw users away from the main project. Being written in Rust is the most compelling reason that I could think of. SQLite has many annoying quirks (foreign key constraints disabled by default and non-strongly-typed columns are my two pain points) but a fork that addresses them would still not pull me away from the original project that I have so much trus…
If I were to fork SQLite, drawing users away from the main project would be a non-goal. The goal would be to get strict tables and foreign key constraints enforced 100% of the time.