[sqlite] Replace an open database

On 05/29/2015 03:27 PM, Zaumseil Ren? wrote: >> On Fri, May 29, 2015 at 8:48 AM, Dan Kennedy <[hidden >> email]> >> wrote: >> >>> On 05/29/2015 12:59 PM, Zaumseil Ren? wrote: >>> On 05/27/2015 11:59 PM, Wade, Wi

[sqlite] Replace an open database

On 05/29/2015 02:35 PM, Dominique Devienne wrote: > On Fri, May 29, 2015 at 8:48 AM, Dan Kennedy wrote: > >> On 05/29/2015 12:59 PM, Zaumseil Ren? wrote: >> >>> On 05/27/2015 11:59 PM, Wade, William wrote: >>> But instead of using a regular SQL transaction to drop all the old tables, use

[sqlite] Replace an open database

On 05/29/2015 12:59 PM, Zaumseil Ren? wrote: > On 05/27/2015 11:59 PM, Wade, William wrote: > >>> 3) The writing thread prefers to delete any existing file. If it can't do >>> that (some readers currently have the file open) it gains an exclusive >>> read/write lock (consistent with no reader has

[sqlite] Replace an open database

On Fri, May 29, 2015 at 8:48 AM, Dan Kennedy wrote: > On 05/29/2015 12:59 PM, Zaumseil Ren? wrote: > >> On 05/27/2015 11:59 PM, Wade, William wrote: >> >>> But instead of using a regular SQL transaction to drop all the old >>> tables, use the backup API to clobber the existing database with the n

[sqlite] Replace an open database

>On Fri, May 29, 2015 at 8:48 AM, Dan Kennedy <[hidden >email]> > wrote: > >> On 05/29/2015 12:59 PM, Zaumseil Ren? wrote: >> >>> On 05/27/2015 11:59 PM, Wade, William wrote: >>> But instead of using a regular SQ

[sqlite] Replace an open database

On 05/27/2015 11:59 PM, Wade, William wrote: >> 3) The writing thread prefers to delete any existing file. If it can't do >> that (some readers currently have the file open) it gains an exclusive >> read/write lock (consistent with no reader has a transaction in progress) >> and truncates the f

[sqlite] Replace an open database

On 05/27/2015 11:59 PM, Wade, William wrote: > I have an application file that I'm considering moving to sqlite. Some > current behavior is: > > 1) Only one writing thread for the lifetime of a logical dataset. > > 2) The writing thread opens the file with exclusive write access (open fails > if

[sqlite] Replace an open database

On Wed, 27 May 2015 19:07:50 +0200 Dominique Devienne wrote: > On Wed, May 27, 2015 at 6:59 PM, Wade, William > wrote: > > > (including his own uuid, indicating that this is logically a new > > file). When existing readers get around to reading again, they will > > check that uuid, and handle t

[sqlite] Replace an open database

On Wed, May 27, 2015 at 6:59 PM, Wade, William wrote: > (including his own uuid, indicating that this is logically a new file). > When existing readers get around to reading again, they will check that > uuid, and handle the change in writers "gracefully." > You can perhaps abuse the Application

[sqlite] Replace an open database

On 27 May 2015, at 5:59pm, Wade, William wrote: > I'm wondering how to implement that behavior while using sqlite as my > application file. I can imagine several solutions, but I'm not sure what > pitfalls to look for. In particular, haven't determined how to get sqlite to > write-open an exi

[sqlite] Replace an open database

I have an application file that I'm considering moving to sqlite. Some current behavior is: 1) Only one writing thread for the lifetime of a logical dataset. 2) The writing thread opens the file with exclusive write access (open fails if there is another writer, no other writers allowed, but on