On Tue, 2007-04-10 at 09:26 -0700, Scott Hess wrote:
> On 4/10/07, Dan Kennedy <[EMAIL PROTECTED]> wrote:
> > I checked the code and conflict handling mechanisms (OR ERROR,
> > OR ABORT, OR REPLACE) do not apply to virtual tables.
> <snip>
> > Something to think about anyhow... Do we want conflict handling
> > for FTS (and other virtual modules)?
>
> I think OR REPLACE would be really unfortunate to lose, it's a pretty
> common idiom (especially using REPLACE in place of INSERT).
>
> Do we really need to have this expressed in the API? If the virtual
> table returned SQLITE_CONSTRAINT from xUpdate(), and guaranteed that
> the table was unmodified, then the core should be able to implement
> all of the variants. I can see how expressing it in the API might
> allow certain implementations to be more efficient.
SQLite could take care of it if the only constraint that can fail is
a duplicate rowid. Just by saying:
if( xUpdate(INSERT)==SQLITE_CONSTRAINT ){
xUpdate(UPDATE);
}
and other variants for UPDATE etc.
But that would leave no way for the virtual table to implement
constraints related to other columns of the virtual table. At
least, that's my reason for thinking it would be better done as
a flag passed to the implementation of xUpdate().
Dan.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
