On 4/11/07, Dan Kennedy <[EMAIL PROTECTED]> wrote:
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().
That makes sense to me. On the flip side, it seems to me like there are fewer cases to handle for xUpdate(). The OR REPLACE case might effectively delete multiple rows in the table, which couldn't be done unless the indices were somehow exposed, or the conflict info was passed in. Virtual tables could conceivably implement a concept of OR REPLACE which simply wouldn't make sense to SQL, so the latter is probably bother easier and more flexible. But wouldn't the other cases all be the same, with xUpdate() returning SQLITE_CONSTRAINT and the core handling things from there? My assumption, here, is that sqlite has already factored things down to the row level. So, for an UPDATE OR FAIL who's WHERE clauses touches 100 rows, but where the 51st update wants to fail with SQLITE_CONSTRAINT, you do want the first 50 rows to be updated but not the last 50. But, if the virtual table does multiple operations to implement a single-row update, you probably _don't_ want only half those operations to persist (even if that doesn't corrupt the table's backing). Instead, you probably want xUpdate() to appear entirely atomic. Basically, the conflict handling on lang_conflict.html seems to me to be implicitly operating at the statement level, with rows considered atomic. -scott ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
