Software: Apache/2.0.54 (Fedora). PHP/5.0.4 

uname -a: Linux mina-info.me 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 

uid=48(apache) gid=48(apache) groups=48(apache)
context=system_u:system_r:httpd_sys_script_t 

Safe-mode: OFF (not secure)

/usr/share/doc/sqlite-devel-3.1.2/doc/   drwxr-xr-x
Free 3.79 GB of 27.03 GB (14.04%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     conflict.html (4.92 KB)      -rw-r--r--

bugs changes contrib cvs repository documentation

download faq home mailing list news

quick start support syntax timeline wiki

Constraint Conflict Resolution in SQLite

In most SQL databases, if you have a UNIQUE constraint on a table and you try to do an UPDATE or INSERT that violates the constraint, the database will abort the operation in progress, back out any prior changes associated with UPDATE or INSERT command, and return an error. This is the default behavior of SQLite. Beginning with version 2.3.0, though, SQLite allows you to define alternative ways for dealing with constraint violations. This article describes those alternatives and how to use them.

Conflict Resolution Algorithms

SQLite defines five constraint conflict resolution algorithms as follows:

ROLLBACK

When a constraint violation occurs, an immediate ROLLBACK occurs, thus ending the current transaction, and the command aborts with a return code of SQLITE_CONSTRAINT. If no transaction is active (other than the implied transaction that is created on every command) then this algorithm works the same as ABORT.

ABORT

When a constraint violation occurs, the command backs out any prior changes it might have made and aborts with a return code of SQLITE_CONSTRAINT. But no ROLLBACK is executed so changes from prior commands within the same transaction are preserved. This is the default behavior for SQLite.

FAIL

When a constraint violation occurs, the command aborts with a return code SQLITE_CONSTRAINT. But any changes to the database that the command made prior to encountering the constraint violation are preserved and are not backed out. For example, if an UPDATE statement encountered a constraint violation on the 100th row that it attempts to update, then the first 99 row changes are preserved by change to rows 100 and beyond never occur.

IGNORE

When a constraint violation occurs, the one row that contains the constraint violation is not inserted or changed. But the command continues executing normally. Other rows before and after the row that contained the constraint violation continue to be inserted or updated normally. No error is returned.

REPLACE

When a UNIQUE constraint violation occurs, the pre-existing row that caused the constraint violation is removed prior to inserting or updating the current row. Thus the insert or update always occurs. The command continues executing normally. No error is returned.

Why So Many Choices?

SQLite provides multiple conflict resolution algorithms for a couple of reasons. First, SQLite tries to be roughly compatible with as many other SQL databases as possible, but different SQL database engines exhibit different conflict resolution strategies. For example, PostgreSQL always uses ROLLBACK, Oracle always uses ABORT, and MySQL usually uses FAIL but can be instructed to use IGNORE or REPLACE. By supporting all five alternatives, SQLite provides maximum portability.

Another reason for supporting multiple algorithms is that sometimes it is useful to use an algorithm other than the default. Suppose, for example, you are inserting 1000 records into a database, all within a single transaction, but one of those records is malformed and causes a constraint error. Under PostgreSQL or Oracle, none of the 1000 records would get inserted. In MySQL, some subset of the records that appeared before the malformed record would be inserted but the rest would not. Neither behavior is especially helpful. What you really want is to use the IGNORE algorithm to insert all but the malformed record.