From their "code of ethics"
- First of all, love the Lord God with your whole heart, your whole soul, and your whole strength.
- Deny oneself in order to follow Christ.
- Fulfill not the desires of the flesh; hate your own will.
There are even more strange ones, but I hope you get the picture. Reason enough to use something else if possible.
If you actually read the page, it's intended as a tongue-in-cheek box-checker.
This document was originally called a "Code of Conduct" and was created for the purpose of filling in a box on "supplier registration" forms submitted to the SQLite developers by some clients.
This document continues to be used for its original purpose - providing a reference to fill in the "code of conduct" box on supplier registration forms.
https://www.theregister.com/2018/10/22/sqlite_code_of_conduct/
They are serious about the religious stuff. And someone who kicks the concept of a code of conduct with their feet like this is surely not a person that is nice to be around.
Thanks, everyone knows they have a weird coc. It obviously only applies to the maintainers/members of the project though and is more of a statement than something that is actually enforced. As a convinced atheist, I also find it pretty weird but see absolutely no reason at all to avoid sqlite because of that. What matters is: Code quality/correctness (which is absolutely superb when it comes to sqlite) and license, of course. Why would I care about the authors beliefs? They don't even directly benefit from me using their product.
@words_number @Sibbo that was one hell of an opening sentence to misread.
Permanently Deleted
Some background: https://www.theregister.com/2018/10/22/sqlite_code_of_conduct/
I would think that's satire of insanely long and irrelevant rules documents.
In other words, the developers are saying: "We will treat you this way regardless of how you treat us."
I dk I don't think you can fake a persecution complex like that.
Holy crap. I've used this thing for years and never had a clue they're a bunch of fruitcakes.
Reason enough to <del>use something else if possible</del> read the docs.
I don't know, SQLite it's something that makes sense in theory, but I think its easier for ops people to just use a proper database. If you need to move the database to a separate machine, limit permissions, etc. its just easier to do.
SQLite is great for local apps that need a structured way to store their data, but I'm not really comfortable using it for more than that.
Permanently Deleted
I typically run postgres locally too (in docker), while there's still technically network overhead there's not much compared to a real network, plus you can easily move it to another machine without reworking your app to switch from SQLite to postgres.
Personally I never do permissions at the database layer anyway - it's always done at the application layer.
I also never move the database to a separate server - that adds too much latency. If your database is local, and "hot" tables are cached in RAM, you can do several hundred thousand queries in a split second and having performance like that can drastically reduce complexity in your business logic (and therefore, drastically reduce bugs).
Regardless, I don't see it as something that is the silver bullet that people make it out to be. Being able to introspect the production database, query it, and generally have a set of tools to properly manage your data as opposed to having everything in a file fully managed by your application is something useful for me that you lose with SQLite.
I've built and deployed specifically small applications using sqlite and yeah I agree with everything, but especially the migration pains. Any change becomes difficult and bringing another developer onto a project just slows it to a crawl when db changes are needed. If that can be resolved I could be convinced, but until them postgres4lyf
Permanently Deleted
SQLite's type system could accurately be described as "there is no type system". And the developers consider it a feature not a bug.
A recently added "STRICT" feature changes that. But it's very rudimentary.
I use SQLite to power up lots of stuff I'm working on. It's lightweight, fast, simple and well-documented for small projects — like a Postgres but very local. Saves me from having to deal with containers "just to store data", let alone for moving stuff to other machine where I would also need the permissions to configure and run containers in the first place; whereas all you need to pass SQLite databases along is
scp/rsync.I love SQLite! My current project actually uses it to serve read-only web content - it's plenty fast, and it's really nice having everything baked into the executable. No need to juggle a separate database server.
Their docs are also superb - maybe I'm weird, but I like reading about stuff like atomic commit.
I love SQLite in the command line. Being able to import data sets into a db that I can quickly write queries for has saved me a lot of data processing time.
The CSV import tool is so useful too. I’ll find myself looking at an excel sheet or something and thinking “if only I could query this like SQL”.
Yes, exactly! I just import the data into SQLite as an in memory db, execute whatever query I want and .output the answer somewhere. It's so easy and clean.
It's an interesting format for passing around information that's best structured as a database, thus useful for one of my current spare-time projects.
it uses a single file on disk as a backing store
While this is the norm, you can have one database in multiple files.
Also, provides benchmarks on a file-based database whithout providing any details on the underlying filesystem.
That was a good read, thanks!
In a world of containers and stateless applications, fuck SQLite.
... you know you can put SQLite in a container right? It doesn't even need to be persisted to disk - it can just live in RAM.
If you don't care about persistence, why are you even using a DB in the first place?
You can always use sqlite cloud
/s?
