On Fri, 18 Mar 2005, Andrew Piskorski wrote:
If besides that one slow update you had ONLY READS (and those reads do not care which version of the data they get, old or new), I'd say sure, fine, an atomic "swap in a totally new db" operation might be worth trying.
But for a database with active reads AND sometimes also writes, all while that big slow update is going on? No, even if your special procedural scheme below works, the whole idea seems misguided. If you really must have the possiblity of other writes while that huge slow update is happening, use an RDBMS which is actually designed to support that scenario, like PostgreSQL. SQLite is the wrong tool.
You proposed procedure below is an ugly hack. I do not know the particulars of your situation, so maybe for you it really is justified over the correct "use PostgreSQL" alternative. But I would think long and hard about that.
(And no, I don't know what the best/simplest way to do an "atomically replace whole db" step is with SQLite. That would be useful to know, regardless.)
yes this is the point. for sure it'd be better to use something else here - but there are certainly times when it would be nice to do atomic updates of sqlite dbs. without this ability you are bascially saying that, once a system goes into production you may never make big changes to the db without blocking all production readers/writers. i agree that, in general, this usage suggests another db - but there are plenty of cicumstances where one might be inclined to use sqlite (say a website backed by an sqlite db where access was 98% reads and 2% writes) where this should still be possible... without this capability it's hard to consider using sqlite unless your client aps are 100% readonly....
-a -- =============================================================================== | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov | PHONE :: 303.497.6469 | When you do something, you should burn yourself completely, like a good | bonfire, leaving no trace of yourself. --Shunryu Suzuki ===============================================================================
