Back when I worked at a large semi conductor company they used GDSII[0] and Calibre[1] files along with internal formats and I always wondered why they wouldn't just use SQLite. SQLite is even threadsafe[2].
The testing each release goes through is quite impressive. I bet more time is spent on testing (or writing tests) than actually developing the features.
SQLite is used on many platforms, built using many compilers. All of those compilers might have bugs themselves (who am I kidding? They do), something verification cannot account for.
It depends—many proof-assistant languages let you extract an implementation directly out of your formally-specified algorithm (generally by dropping rich typing-ish information, but you've already verified it's correct). Or take seL4, which amazingly proves that not just the C code but also the binary faithfully matches their formally-specified algorithms. https://sel4.systems/Info/FAQ/proof.pml
Of course who knows what your CPU microcode is doing, but for the question at hand—ensuring a highly portable C library does what it claims to do more efficiently and accurately than exhaustive testing—formal verification is certainly a reasonable approach.
I would contribute towards a Wall St Journal full page ad "SQLite: Most widely used DB in the world" with little misleading graphs comparing to Oracle and DB2
No. In reality, it's incredibly hard to migrate any database to another database. Even if you have high test coverage, there can be some corner cases bite you later. Hack, simply a version upgrade can have all kinds of problems.
> SQLite is likely used more than all other database engines combined. Billions and billions of copies of SQLite exist in the wild. SQLite is found in:
> Every Firefox, Chrome, and Safari web browser
Where is SQLite in Firefox? It would be wonderful to use SQL in the browser, on the server, in mobile devices (everywhere!), but alas I suspect SQLite can be "found" in Firefox as the underlying storage engine on top of which IndexedDB is built.
I believe that quotation is just saying that Firefox uses SQLite to store some of its internal state, not that it has an API to interact with general SQLite databases.
> not that it has an API to interact with general SQLite databases
Well, it did, but they removed it, and in fact spearheaded the movement to deprecate WebSQL circa 2010...when Firefox had significant marketshare. Chrome and Safari still, 10 years later, ship with WebSQL support, which makes it pretty clear which side of the fence they're on.
and very much still is in Chrome and Safari, nearly 10 years after WebSQL was "deprecated". Firefox removed WebSQL, replacing it with IndexedDB, a simple k -> v store.
Cross platform SQL everywhere? Not with Firefox still in the mix.
Considering the Type-flexibility of SQLite, would it necessarily be too difficult to have an object-relational mapping that works across both DB's?
I guess it depends on the application. Surely it would be a pain, but perhaps still a possibility.
A C# native port[0] of Sqlite was attempted in 2009 and eventually abandoned in 2012. It was a lot of work and the developer didn't get 100% of the verification tests to pass.
To be fair to the programmer, he said the C-to-C# translation was mostly a self-learning exercise rather than a serious attempt at creating a production-quality library.
I think the obvious answer is that there's no market demand for a C# native version of SQLite. People just use the C# ADO.NET wrapper that calls the "unsafe" C compiled DLL[1]. Using that method, it's easier to stay up-to-date with the canonical C source code that has the latest bug fixes and new features. If you look at high frequency of updates in the release history[2], you can see that constantly porting the new C code to C# to maintain feature parity would be a tremendous amount of work.
Also, if you create a C to C# port, it means using the C Language style API such as "sqlite3_open()" instead of the more natural C# paradigm of ADO.NET "new SQLiteConnection(@"Data Source=x")". Somebody would than have to write another ADO.NET wrapper to specifically interface with the C# port of SQLite.
> Also, if you create a C to C# port, it means using the C Language style API
Is this really necessary? Is it impossible to just write a .Net-native library with whatever an API that would just open an SQLite file and run SQL queries against it? As for me that's all I ever needed of it.
>Is it impossible to just write a .Net-native library with whatever an API
It's not impossible but the issue is whether it's worth the amount of effort involved. So yes, you can theoretically write the C# code in any way that makes a convenient API for the C# coder.
But when attempting real-world implementations, there are varying degrees of difficulty/maintainability of porting the C code to C#. You want to balance the tradeoffs of minimizing the C# programming code effort and maximizing the leverage of the original C source code. The effort continuum would look something like this:
- easy: unsafe C DLL with C# ADO.NET wrapper (the 'C' source code is mostly unchanged and is leveraged for highest reuse; this is what we have today)
- harder: straight C-to-C# port with extra C# code to provide an ADO.NET wrapper (an automated tool can attempt to transpile most of the C into C# which is followed up by a human programmer to manually fix/code the parts the transpiler couldn't; this effort was attempted in 2009 and the incomplete project was eventually abandoned)
- hardest: C-to-C# total rewrite where the programmer built in an ADO.NET api (or whatever API the C# programmer wants to expose). In this way the original SQLite C source is more of a "specification" rather than an input file to a transpiler.
The "harder" effort which wasn't even 100% complete was abandoned. It means the "hardest" implementation, while technically not impossible, is even more unrealistic for anyone to code and maintain. That last method of C# rewrite has immense costs and would fall further and further behind the original C source code in feature parity and bug fixes.
To answer your question on why there are no alternative implementations: it's because it's a lot of programming work that nobody wants to do.
I know it's written in C. And it usually takes hours of shamanic dances to make it work in a Visual Studio WinForms app (while performance is rarely important for these projects).
No, even if you count that as a database, it isn't the most deployed. Look at the list in the article. SQLite is on every Android device and Windows 10 device, and many/most personal computers with other operating systems (including earlier Windows versions). There are more Android devices in use than Windows ones: https://www.computerworld.com/article/2919104/windows-pcs/wh...
