Agreed - it seems like this would be useful enough functionality that I'm not sure everyone who needs it should be reinventing the wheel...
So is it fair to say that the sqlite3_file API methods are not useful for this purpose? The docs are a bit sparse regarding their intended purposes. On 10/10/07, John Stanton <[EMAIL PROTECTED]> wrote: > > There is a good case to have an Sqlite API call to take a snapshot of a > database. It would integrate with the locking logic and secure an > exclusive lock before taking the snapshot. That is a safer and handier > approach than extracting a file descriptor and perhaps creating mayhem. > > Cyrus Durgin wrote: > > Maybe it would help to state my use case: without this functionality, > what > > is the proper way to copy a database using the C API without introducing > a > > race condition? > > > > On 10/9/07, Robert Simpson <[EMAIL PROTECTED]> wrote: > > > >>>-----Original Message----- > >>>From: Cyrus Durgin [mailto:[EMAIL PROTECTED] > >>>Sent: Tuesday, October 09, 2007 5:02 PM > >>>To: sqlite-users@sqlite.org > >>>Subject: [sqlite] how to get file handle from sqlite3 object? > >>> > >>>i'm wondering if there's a "standard" way to get an open file > >>>handle from an > >>>sqlite3 pointer using the C API. anyone know? > >>> > >> > >>There's no public way to get this, nor should there be. The internal > >>implementation of the database should be kept separate from the logical > >>API > >>to access it. Such a function would muddy the water between > >>implementation > >>and interface and hamper the ability to change the implementation > without > >>changing the interface. > >> > >>Not all filesystems would be able to return one, nor could it guarantee > >>that > >>the database is in fit state for someone to fiddle with its internal > >>handle. > >>Furthermore, it could not be guaranteed that once a caller obtained the > >>handle that the caller might then do something damaging to it or alter > its > >>state. > >> > >>Such a function definitely falls into the BAD IDEA category, IMO. > >> > >>Robert > >> > >> > >> > >> > > >>----------------------------------------------------------------------------- > >>To unsubscribe, send email to [EMAIL PROTECTED] > >> > > >>----------------------------------------------------------------------------- > >> > >> > > > > > > > > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > > ----------------------------------------------------------------------------- > > -- Cyrus. <[EMAIL PROTECTED]>
