To be fair the ten commandments were written on a tablet.
SQLite creator crucified after code of conduct warns devs to love God, and not kill, commit adultery, steal, curse...
Open-source database SQLite has told its developers it expects them to follow Christ, love chastity, clothe the naked, and not murder, steal, nor sleep with their colleagues' spouses. That's the upshot of a somewhat untypical code of conduct that the widely used project has published online. While most code of conducts take an …
-
-
-
Tuesday 23rd October 2018 13:06 GMT Anonymous Coward
There were more than ten. Got censored really early.
As it later turned out, all that guff about not killing people, not committing adultery and so on got ignored almost immediately, while the stuff about not eating prawns was rigorously enforced.
Proof if it were needed that sex is better than shellfish.
-
Monday 22nd October 2018 21:02 GMT ThomH
Not the first piece of absurd preaching to come from the SQLite team
To quote the FAQ:
(6) Is SQLite threadsafe?
Threads are evil. Avoid them.
SQLite is threadsafe. We make this concession since many users choose to ignore the advice given in the previous paragraph.
After I've realised why it's evil not to throw away 75%+ of the processing power available to my application, I'll worry about the other strictures emanating from the SQLite team.
-
Tuesday 23rd October 2018 06:15 GMT Christian Berger
Re: Not the first piece of absurd preaching to come from the SQLite team
"After I've realised why it's evil not to throw away 75%+ of the processing power available to my application,"
Well but for the typical usecase of SQLite threads bring more problems than they are worth. If you want to have software that can have it's database hammering with multiple processors on multiple harddisks you shouldn't use SQLite but some sort of "real" SQL-Server.
The whole idea behind SQLite is that you'll have the good things about SQL without having to have an extra server.
-
Tuesday 23rd October 2018 07:59 GMT DaLo
Re: Not the first piece of absurd preaching to come from the SQLite team
" If you want to have software that can have it's database hammering with multiple processors on multiple harddisks ..."
Doesn't necessarily mean this. You may have high intensity procedures doing significant number crunching running on multiple threads which are just storing and retrieving small amounts of data from the SQLite database. The database isn't being hammered or particularly big but it still needs to be accessible and consistent across multiple threads.
-
Tuesday 23rd October 2018 08:13 GMT Christian Berger
Re: Not the first piece of absurd preaching to come from the SQLite team
"The database isn't being hammered or particularly big but it still needs to be accessible and consistent across multiple threads."
So you just need one lock around the database functions. That's apparently what they have implemented.
-
-
Tuesday 23rd October 2018 08:35 GMT Charlie Clark
Re: Not the first piece of absurd preaching to come from the SQLite team
The whole idea behind SQLite is that you'll have the good things about SQL without having to have an extra server.
I think your claims about SQL are a bit ambitious: it effectively grafts SQL onto a two-typed CSV storage designed for single user access.
-
-
Tuesday 23rd October 2018 12:32 GMT ThomH
Re: Not the first piece of absurd preaching to come from the SQLite team
The FAQ doesn't attempt to scope its verdict on threads to SQLite; it does however state an advocacy position, contrary to the norm, citing only a single decade-old paper. Being persuasive is, at best, a fleeting consideration.
But on the whole implementation thing: after the hard stuff of statement parsing SQLite's underlying store is just sorted lists for binary search. So this feels like exactly what readers-writer locks are for: there's a simple, robust, well-documented, well-informed told, widely-implented solution. And then there's just proclaiming a deeply-held conviction.
-
-
-
-
Tuesday 23rd October 2018 07:23 GMT Paul Crawford
Re: Not the first piece of absurd preaching to come from the SQLite team
To be fair here I have of agree with the "threads are evil" thing. Trying to debug code that lacks repeatability due to some thread interaction that is not deterministic (due to variable run-time timing, or due to an asynchronous event) is definitely the Devil's work. Yes, there are synchronisation primitives to (hopefully) work around it, but then you get in to the OS war zone.
Stick to multiple single-thread processes where possible...at least such a process can be expected to behave the same for the same inputs, and if not that alone is a bug.
-
Tuesday 23rd October 2018 12:49 GMT Ian Michael Gumby
Re: Not the first piece of absurd preaching to come from the SQLite team
Actually, if you read the last line... it could explain why he chose this as the CoC:
"nor sleep with their colleagues' spouses."
That said, anyone who claims threads to be evil doesn't know how to use and manage threads.
It separates the men from the posers.
-
-
Tuesday 23rd October 2018 16:34 GMT doublelayer
Re: Not the first piece of absurd preaching to come from the SQLite team
Threads are problematic because they can cause a lot of annoying race condition/concurrency problem things. That doesn't make them evil any more than the compiler is evil because it optimizes code into a method that makes it hard to debug, or the operating system is evil because it limits the number of open files you can have. They work in some way, and they each have a reason to do so.
Threads are useful over processes because your code is more united; you can create threads that are nicely connected to a codebase while multiprocessing is uglier. Threads let you have interactions between each other whereas processes don't have convenient communication mechanisms (sighup is not enough). To communicate between processes, you usually have to create your system yourself and it's slower.
As for SQLite, I typically use it only as a convenient type of data storage, or for an application that needs a local database inside itself. For real database requirements, it's not going to have enough features or capacity.
-
-
-
-
-
Tuesday 23rd October 2018 07:51 GMT Christian Berger
"tell that to people murdered in crusades or by inquisition,"
That's like saying that being nice to each other is bad, just because there are SJWs out there who shitstorm everybody who doesn't fullfill their believes.
Any sort of belief can be used to aflict harm on people, particularly if it doesn't have any safeguards against that.
This set of rules starts with the idea that you can never fullfill them all, they are explicitly guidelines not strict rules. This makes them far more humane than any other CoC I've read so far as it accepts errors made with good intentions.
-
-
-
Biting the hand that feeds IT
