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]>

Reply via email to