I too, like Basil Thomas, like Andrew's writeup. Well-reasoned.
Like it or not... all programs start simple and evolve to a level unsupportable complicatedness until the developer's either lose interest or the program gets bought out by Microsoft.
We use SQLite because we like it. The more we use it, the more we will run into "one more thing that, if it could do, would be so great" problem. Introducing that capability will make SQLite that much more useful, and that much more complicated, hence different from what attracted us to it. But, hey... there is no way out of it.
If I am using SQLite, and it works great, it would be a shame to abandon it just because it can't or won't do that one thing that I want it to do. SQLite is really wonderful, and fast as all heck (yesterday I ran comparative tests against SQLite, Access, SQL Server, and Berkeley DB... SQLite blew all the relational dbs out of the water... it was only beaten by Bdb -- I guess there is nothing faster than in-memory manipulation of hash tables). But, I do miss some simple things such as ALTER table command, some not-so-simple things such as row-level locking, and am puzzled by some (IMO) quirky things such as croaking on parens (ref. my recent posts on this subject) or not auto-aliasing table.columnnames as columnnames...
Well, that's it. The better SQLite gets, the more folks will use it, and the more folks will use it, the more different uses/conditions they will use it in, and the more they do that, the more new features they will desire.
Everything rises in complexity until it collapses. Until then, lets enjoy the ride.
On May 6, 2004, at 12:22 PM, [EMAIL PROTECTED] wrote:
I really like this answer!!!
The Goldilocks approach to increased concurrency...
Hopefully DRH will read your answer and conclude this would be a good
approach
as the current take it or leave it answers are no help.
Abandoning SQLite COMPLETELY for higher concurrency does not make sense but
a third solution for medium ground between the two current extreme views to
SQLite concurrency
would be much appreciated.
I wish I could work on this locking solution but my hands are tied because
SQLite currently runs quite well in our current application and therefore
many more features
have been requested...such as supporting more users!!!
-----Original Message----- From: Andrew Piskorski [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 12:53 PM To: [EMAIL PROTECTED] Subject: Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 09:54:24AM -0400, D. Richard Hipp wrote:
Concurrency is not nearly as much an issue in reality as it is in many peoples imagination. Concurrency probably is not an issue for a website. If concurrency really is an issue, you need a client/server database.
While that might be true [I take no position on whether it is or not], to some real extent it may also be irrelevent. Here's my theory:
People often don't know ahead of time, and aren't able to reasonably predict, just how much concurrency they will need. Also, their concurrency needs may change over time, again in ways that are hard for them to predict.
Therefore, picking a tool which they KNOW has serious concurrency limitations introduces a significant risk, the risk that they may have to drastically overhaul their underlying tools and architecture at some unknown point in the future, due to hitting concurrency problems and thus suddenly discovering that they're now using the wrong tool for the job.
Since SQLite's concurrency support is very limited, potential users are forced to pre-maturely optimize: Either believe you will need high concurrency, and go with PostgreSQL or Oracle, or believe you will need no or low concurrency, and go with SQLite. Premature optimization is a bad thing.
There is a missing middle ground there: A medium-concurrency SQLite.
If a future version of SQLite - let's call it "SQLiteMC" - were able to significantly increase concurrency, while at the same time preserving all or most of SQLite's historical advantages (simplicity, etc.), this would significantly expand the problem domain to which SQLite is applicable. That, in turn, would reduce the "wrong tool" risk of using SQLite, and both of those effects would tend to make SQLiteMC both more useful and more widely used than SQLite is now.
That's my little mental model anyway. To me the direction of those effects seems just about certain, but what I don't know - and can't know, much less quantify - is the size of those effects - they could be anywhere from zero to large. And of course, that's assuming that SQLiteMC succeeds in its technical goals.
And would SQLiteMC succeed in its technical goals? How hard would it be, and are there sufficient programmer resources available to make it happen? That I don't really know either, but together, Dr. Hipp plus a few other experts on this list could probably come up with a reasonably good idea...
-- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
============================================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
