Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Work on SQLite4 has concluded

sqlite.org

Post reply on HN
Print view View original

151–160 of 161 posts

Re: Work on SQLite4 has concluded

#151

Post by scott_karana »

hasenj wrote: post #83
bane wrote: post #73

SQLite is one of those awesome things that's the exact opposite of magic. It's beautiful, jaw dropping, engineering that exercises so many technical muscles. The number of oddball, often critical, places where I've found SQLite being used would defy belief. As far as I can tell, the "expected" place for SQLite to work seems to be almost anything that's not your normal dB driving some web-based CRUD app...all kinds of…

> your normal dB driving some web-based CRUD app That can totally be handled with SQLite.

Not if you need to use multiple app servers.

Re: Work on SQLite4 has concluded

#152

Post by ngrilly »

raphaelj wrote: post #118
sametmax wrote: post #88

Earlier quoted context omitted.

I have several crud apps running sql. With moderate write load and a good concurrency write error handling code it works very well. Good when the product size is not worth a postgres full blown setup.

I backup this. I've been using SQLite for some low to moderate load CRUD apps, and this always worked like a charm. SQLite also make backuping, testing and moving apps so much easier.

How do you workaround the fact that SQLite only supports a single writer? For example, your app could be blocked when you run a long operation like creating an index.

Re: Work on SQLite4 has concluded

#153

Post by ngrilly »

geocar wrote: post #132
Daycrawler wrote: post #129

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…

How do you workaround the fact that SQLite only supports a single writer? For example, your app could be blocked when you run a long operation like creating an index.

Re: Work on SQLite4 has concluded

#154

Post by sametmax »

ngrilly wrote: post #152
raphaelj wrote: post #118

Earlier quoted context omitted.

I backup this. I've been using SQLite for some low to moderate load CRUD apps, and this always worked like a charm. SQLite also make backuping, testing and moving apps so much easier.

How do you workaround the fact that SQLite only supports a single writer? For example, your app could be blocked when you run a long operation like creating an index.

For moderate load: just catch the exception and try again. It will rarely happen, and when it does, you can easily recover from it since your site is not hammered.

For bigger load, have a worker that does the writes with a queue.

Re: Work on SQLite4 has concluded

#155

Post by oh_sigh »

bch wrote: post #32
oh_sigh wrote: post #30

Earlier quoted context omitted.

What kind of companies sign 35 year support contracts?

The kind that give away their product for free, give the company to their wife, develop an in-house distributed version control (fossil (which is excellent)), give that away for free and encourage other version control projects to please steal ideas from fossil. drh (Richard Hipp) is an interesting duck.

Presumably Hipp doesn't sign a 35 year support contract with his own company?

Re: Work on SQLite4 has concluded

#156

Post by ngrilly »

sametmax wrote: post #154
ngrilly wrote: post #152

Earlier quoted context omitted.

How do you workaround the fact that SQLite only supports a single writer? For example, your app could be blocked when you run a long operation like creating an index.

For moderate load: just catch the exception and try again. It will rarely happen, and when it does, you can easily recover from it since your site is not hammered. For bigger load, have a worker that does the writes with a queue.

Hello Sam and/or Max,

I'm French too and I read your blog sometimes ;-)

Is the following what you suggest:

You create an index, and the index creation takes 30 seconds. Then instead of writing directly to SQLite (which won't work since the index creation blocks other writers) you suggest to store the write in a queue (for example another SQLite database for durability), and have a worker apply the write to the main database when the index creation is done?

Re: Work on SQLite4 has concluded

#157

Post by triangleman »

sharpercoder wrote: post #74

Every time I see something about sqlite, I become sad. It reminds me of the failure of the w3 standards comittee to accept it as web standard. They rejected sqlite because no competing implementation existed. Furthermore, "public domain" license of the software was also a hurdle, iirc.

That is strange, for some reason I was under the impression that all browsers natively support sqlite. I even installed a Chrome extension when I wanted a gui to browse sqlite db's. I am disappointed to hear this.

Re: Work on SQLite4 has concluded

#158

Post by hasenj »

ngrilly wrote: post #153
geocar wrote: post #132

Earlier quoted context omitted.

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…

How do you workaround the fact that SQLite only supports a single writer? For example, your app could be blocked when you run a long operation like creating an index.

SQLite supports concurrent reads and writes since 2010 with the introduction of the "write ahead log"

https://sqlite.org/wal.html

Re: Work on SQLite4 has concluded

#159

Post by ngrilly »

hasenj wrote: post #158
ngrilly wrote: post #153

Earlier quoted context omitted.

How do you workaround the fact that SQLite only supports a single writer? For example, your app could be blocked when you run a long operation like creating an index.

SQLite supports concurrent reads and writes since 2010 with the introduction of the "write ahead log" https://sqlite.org/wal.html

Yes, but with a single writer at a time.

From the link you shared: "However, since there is only one WAL file, there can only be one writer at a time".

Re: Work on SQLite4 has concluded

#160

Post by dude01 »

bambax wrote: post #101
smitherfield wrote: post #89

Earlier quoted context omitted.

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.

I too am so disappointed SQLite isn't available in modern browsers (esp. since it was, for a time). But can't it be resurrected? Couldn't we set up a petition somewhere to bring it back?

Actually, it's still available in Chrome, Safari and Opera. I guess Firefox and IE still don't have it.
Post reply on HN