131–140 of 161 posts
Earlier quoted context omitted.
CockroachDB has a good blog post[0] that describes how they implemented SQL. (CockroachDB is a key-value store.) [0] https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mappin...
>(CockroachDB is a key-value store.) Correction: CockroachDB is based on a KV store, it's a full SQL RDBMS on top of this KV store.
Earlier quoted context omitted.
> your normal dB driving some web-based CRUD app That can totally be handled with SQLite.
Unless you want to scale. I'm all for the rule of least power, but as soon as the app is exposed to multiple users I would ask and be sure about the expected number of simultaneous users before going with SQlite instead of going with a Client/Server RDBMS. Still, the bound is pretty high if you keep your transactions short.
I am beginning to suspect that MySQL, PostgreSQL, DB2, Oracle, BigTable, and others allow one to get so far with the wrong architecture, that maybe some even very experienced programmers believe that to go faster they have no choice but more threads.
Would love to hear some of the lessons learned...
Earlier quoted context omitted.
We literally lost several years for web app advancement because of that. Reading the decision making, it seemed like overly-legalistic engineers, but I'm open to conspiracy theories that this decision enhanced mobile app store adoption.
No, it was Mozilla who killed it[1] over Apple and Google's strong objections. [1] For pretty much complete nonsense NIH and standards-lawyering reasons.
You consider the fact that there is no spec other than "how the current implementation works", so no way to know if the code than works on version n will continue to work on version n+1, and no way to produce an alternate implementation, is a "complete nonsense reason"?
I also believe that it wasn't just Mozilla, but also Microsoft that scuttled this. Mozilla was the louder voice, but Microsoft never supported it either.
Earlier quoted context omitted.
I didn't downvote, but I don't think it's too much to ask for commenters to read the linked web site carefully before they jump in with a comment. The answer is literally in the link.
It's not too much to ask. A person overlooked a thing once. Heck, I overlooked it too because on my phone the green text was so incredibly small I coudln't read it. I don' think it's too much to ask for commenters to have a little charity.
For context, SQLite4 explored reimplementing SQLite using a key-value store on log-structured merge trees, like RocksDB and Cassandra. I'd be interested to hear why they stopped. Presumably reimplementing SQL on a KV store was seen as not worth it, when applications that are satisfied with an embedded KV store backend (which is much faster and simpler to write!) already have many options.
Shameless plug https://github.com/maxpert/lsm-windows (I did port the LSM storage to windows).
Richard Hipp has said that they have signed contracts to support SQLite3 for 35 years. SQLite4 is never going to happen.
I cant even imagine working on the same project for 35 years... let alone how different computing might be after that time.
Earlier quoted context omitted.
Unless you want to scale. I'm all for the rule of least power, but as soon as the app is exposed to multiple users I would ask and be sure about the expected number of simultaneous users before going with SQlite instead of going with a Client/Server RDBMS. Still, the bound is pretty high if you keep your transactions short.
If you have the correct architecture, multiple users shouldn't matter at all-- I have used SQLite to store and query activity data with something like 10k concurrent "users" without difficulty on a single machine. I am beginning to suspect that MySQL, PostgreSQL, DB2, Oracle, BigTable, and others allow one to get so far with the wrong architecture, that maybe some even very experienced programmers believe that to go…
Richard Hipp has said that they have signed contracts to support SQLite3 for 35 years. SQLite4 is never going to happen.
I cant even imagine working on the same project for 35 years... let alone how different computing might be after that time.