More of sqlite's sloppyness is detailed here https://sqlite.org/src/wiki?name=StrictMode
SQLite is not a toy database
201–210 of 364 posts
Re: SQLite is not a toy database
#202Earlier quoted context omitted.
There's also a pretty nice built-in sqlite extension for transitive closures that helps in searching hierarchical/tree structures in sqlite: https://web.archive.org/web/20141127001741/https://charlesle...
Clicking the above link takes me to https://imgur.com/32R3qLv . I fail to understand why have a blog at all if its author don't like people linking to it.
Re: SQLite is not a toy database
#203Earlier quoted context omitted.
> SQLite doesn't really enforce column types[0], the choice is really puzzling to me. This is acknowledged as a likely mistake, but one that will never be fixed due to backward compatibility: > Flexible typing is considered a feature of SQLite, not a bug. Nevertheless, we recognize that this feature does sometimes cause confusion and pain for developers who are acustomed to working with other databases that are more…
> but one that will never be fixed due to backward compatibility I wonder if a fork/"new version" could address this. Like, sqlite2 (v1.0, etc.).
Re: SQLite is not a toy database
#204Earlier quoted context omitted.
So if you're saying everything does support a web database... then what's the reason people aren't using it for websites? Why do you say it works for "small" websites but presumably not large ones? If it's not transactions, concurrent reading, backups, or administrative tasks... then what's the issue you run into? Genuinely curious... I'm wondering if everything I've heard about "don't use SQLite for websites" is wro…
I think one valid fear is that a web application might, for multiple reasons, scale beyond a single process on a single server. This is common enough that using an embedded database can be problematic, compared to a separate RDBMS process that can be shared between processes. Some web applications are just never going to scale out for any reason, and for those SQLite might be appropriate.
Re: SQLite is not a toy database
#205Two major gripe I had with SQlite 1. SQLite doesn't really enforce column types[0], the choice is really puzzling to me. Since schema enforced type check is one of the strong suit of SQL/RDMBS based data solution. 2. Whole database lock on write, this make it unsuitable to high write usages like logging and metric recording. WAL mode will help but it will only alleviate the issue, you will need row based lock solutio…
> But lesser known is that there is a branch of SQLite that has page locking, which enables for fantastic concurrent write performance. Reach out to the SQLite folks and I’m sure they’ll tell you more
Re: SQLite is not a toy database
#206Earlier quoted context omitted.
There's also a pretty nice built-in sqlite extension for transitive closures that helps in searching hierarchical/tree structures in sqlite: https://web.archive.org/web/20141127001741/https://charlesle...
Clicking the above link takes me to https://imgur.com/32R3qLv . I fail to understand why have a blog at all if its author don't like people linking to it.
Re: SQLite is not a toy database
#207Earlier quoted context omitted.
And LibreOffice has Base, a sadly often neglected component.
Another issue with Base is the required JRE. Installing the JRE may be trivial, but it means that an error message is the first experience most people will have with Base. As for Access, it's access is limited due to the much higher price point of Business/Professional versions of Office. In terms of office suites, that version is about two to three times more expensive than an equivalent office suite from the mid-19…
I thought that they dropped JRE requirement when the engine was switched to Firebird? Googling around apparently the transition wasn't quite successful :(
https://ask.libreoffice.org/en/question/279711/firebird-dead...
Re: SQLite is not a toy database
#208> There is a popular opinion among developers that SQLite is not suitable for the web, because it doesn’t support concurrent access. No, the issue is it doesn't have high availability features: failover, snapshots, concurrent backups, etc. (Edit: oops, comment pointed out it does have concurrent backups.) SQLite isn't a toy DBMS, it's an extremely capable embedded DBMS. An embedded DBMS is geared towards serving a si…
Check out rqlite ( https://github.com/rqlite/rqlite ) for that functionality - "rqlite is a lightweight, distributed relational database, which uses SQLite as its storage engine. Forming a cluster is very straightforward, it gracefully handles leader elections, and tolerates failures of machines, including the leader. rqlite is available for Linux, macOS, and Microsoft Windows."
It absolutely has good use cases, but those are rather niche. You'll mostly be better off with the traditional postgres etc.
Re: SQLite is not a toy database
#209Earlier quoted context omitted.
Backups.
Does that mean it's okay for your application to loose transactions (which occured between the backup point and the failure point) or do you have other mitigations ?
* I'm worried about my server blowing up: Transactions have to be committed to more than one DB on separate physical hosts before returning.
* I'm worried about my datacenter blowing up: Transactions have to be committed to more than one DB in more than one DC before returning.
Re: SQLite is not a toy database
#210SQLite is a really neat thing. I was looking at extensions and how to augment it; you could even add a pg_notify -like feature: https://sqlite.org/c3ref/update_hook.html and have worker processes doing what would amount to out of process stored procedures in postgres (or UDF in SQLite) -- in any language you'd like. You can only register one callback per table tho, although you could from this callback fire other fun…