在线文档教程
Sqlite

SQLite Session Module C/C++ Interface

SQLite会话模块C/C++接口

该页面定义了SQLite会话扩展的C语言接口。这不是教程。这些页面的设计精确,不容易阅读。教程可单独提供。

该页面包含单个HTML文件中的所有C语言接口信息。如果您愿意,也可以将相同的信息分解成许多小页面以便于查看。

这个文档是由一个脚本创建的,该脚本扫描源代码文件sqlite3session.h中的注释。

对象:

  • sqlite3_changegroup

  • sqlite3_changeset_iter

  • sqlite3_session

常量:

  • SQLITE_CHANGESET_ABORT

  • SQLITE_CHANGESET_CONFLICT

  • SQLITE_CHANGESET_CONSTRAINT

  • SQLITE_CHANGESET_DATA

  • SQLITE_CHANGESET_FOREIGN_KEY

  • SQLITE_CHANGESET_NOTFOUND

  • SQLITE_CHANGESET_OMIT

  • SQLITE_CHANGESET_REPLACE

函数:

  • sqlite3changegroup_add

  • sqlite3changegroup_add_strm

  • sqlite3changegroup_delete

  • sqlite3changegroup_new

  • sqlite3changegroup_output

  • sqlite3changegroup_output_strm

  • sqlite3changeset_apply

  • sqlite3changeset_apply_strm

  • sqlite3changeset_concat

  • sqlite3changeset_concat_strm

  • sqlite3changeset_conflict

  • sqlite3changeset_finalize

  • sqlite3changeset_fk_conflicts

  • sqlite3changeset_invert

  • sqlite3changeset_invert_strm

  • sqlite3changeset_new

  • sqlite3changeset_next

  • sqlite3changeset_old

  • sqlite3changeset_op

  • sqlite3changeset_pk

  • sqlite3changeset_start

  • sqlite3changeset_start_strm

  • sqlite3session_attach

  • sqlite3session_changeset

  • sqlite3session_changeset_strm

  • sqlite3session_create

  • sqlite3session_delete

  • sqlite3session_diff

  • sqlite3session_enable

  • sqlite3session_indirect

  • sqlite3session_isempty

  • sqlite3session_patchset

  • sqlite3session_patchset_strm

  • sqlite3session_table_filter

更改组句柄

typedef struct sqlite3_changegroup sqlite3_changegroup;

更改集Iterator句柄

typedef struct sqlite3_changeset_iter sqlite3_changeset_iter;

会话对象句柄

typedef struct sqlite3_session sqlite3_session;

将变更集添加到变更组

int sqlite3changegroup_add(sqlite3_changegroup*, int nData, void *pData

将缓冲区pData(size nData个字节)中变更集(或补丁集)内的所有更改添加到更改组。

如果缓冲区包含一个补丁集,则之前在同一个变更组对象上调用此函数时也必须具有指定的补丁集。或者,如果缓冲区包含变更集,则必须先调用此函数。否则,将返回SQLITE_ERROR,并且不会将更改添加到更改组。

变更集和变更组中的行由其PRIMARY KEY列中的值标识。如果两行具有相同的主键,则更改集中的更改将被视为应用于同一行,作为更改组中已存在的更改。

对尚未出现在更改组中的行的更改将被简单地复制到其中。或者,如果新变更集和更改组都包含适用于单个行的更改,则更改组的最终内容取决于每个更改的类型,如下所示:

现有变更新变化输出变化
INSERTINSERT新的变化被忽略。如果在变更组已经添加到变更组后立即记录新变更集,则不会发生此情况。
INSERTUPDATEINSERT更改保留在更改组中。INSERT更改中的值被修改,就像该行由现有更改插入一样,然后根据新更改进行更新。
INSERTDELETE现有的INSERT已从更改组中删除。DELETE不被添加。
UPDATE INSERT新的变化被忽略。如果在变更组已经添加到变更组后立即记录新变更集,则不会发生此情况。
UPDATEUPDATE现有的UPDATE保留在更改组中。它被修改,以便伴随的值就好像该行已被现有更改更新一次,然后再被新更改更新。
UPDATE DELETE现有的UPDATE被更改组中的新DELETE替换。
DELETE INSERT如果新更改插入的行中的一个或多个列值与现有更改删除的行中的列值不同,则现有的DELETE被更改组中的UPDATE替换。否则,如果插入的行与删除的行完全相同,则仅删除现有的DELETE。
DELETEUPDATE新的变化被忽略。如果在变更组已经添加到变更组后立即记录新变更集,则不会发生此情况。
DELETE DELETE新的变化被忽略。如果在变更组已经添加到变更组后立即记录新变更集,则不会发生此情况。

如果新变更集包含对已存在于变更组中的表的更改,则该表的列数和主键列的位置必须一致。如果不是这种情况,那么这个函数将失败,并且SQLITE_SCHEMA。如果输入更改集看起来损坏并且检测到损坏,则返回SQLITE_CORRUPT。或者,如果在处理期间发生内存不足的情况,该函数将返回SQLITE_NOMEM。在所有情况下,如果发生错误,则变更组的最终内容未定义。

如果没有发生错误,则返回SQLITE_OK。

删除变更组对象

void sqlite3changegroup_delete(sqlite3_changegroup*

创建一个新的变更组对象

int sqlite3changegroup_new(sqlite3_changegroup **pp

sqlite3_changegroup对象用于将两个或更多变更集(或补丁集)组合到一个变更集(或补丁集)中。单个更改组对象可以组合变更集或补丁集,但不能同时包含这两个变更集。输出总是与输入格式相同。

如果成功,此函数将返回SQLITE_OK,并在返回之前用指向新sqlite3_changegroup对象的指针填充(* pp)。调用者最终应该通过调用sqlite3changegroup_delete()来释放返回的对象。如果发生错误,则返回SQLite错误代码(即SQLITE_NOMEM)并将* pp设置为NULL。

sqlite3_changegroup对象的常用使用模式如下所示:

  • 它是通过调用sqlite3changegroup_new()创建的。

  • 通过调用sqlite3changegroup_add()将零个或多个变更集(或补丁集)添加到对象中。

  • 通过调用sqlite3changegroup_output(),应用程序获得将所有输入变更集合在一起的结果。

  • 使用对sqlite3changegroup_delete()的调用删除该对象。

可以在对new()和delete()的调用之间进行任何次数的add()和output()调用。

除了常规的sqlite3changegroup_add()和sqlite3changegroup_output()函数外,还可以使用流版本sqlite3changegroup_add_strm()和sqlite3changegroup_output_strm()。

从变更组中获取复合变更集

int sqlite3changegroup_output( sqlite3_changegroup*, int *pnData, /* OUT: Size of output buffer in bytes */ void **ppData /* OUT: Pointer to output buffer */

获取一个包含表示变更组当前内容的变更集(或补丁集)的缓冲区。如果变更组的输入本身是变更集,则输出是变更集。或者,如果输入是补丁集,则输出也是补丁集。

与sqlite3session_changeset()和sqlite3session_patchset()函数的输出一样,所有与单个表相关的更改都会在此函数的输出中组合在一起。表的顺序与添加到变更组中的第一个变更集的顺序相同。如果添加到更改组的第二个或更多后续更改集包含未出现在第一个更改集中的表的更改,则它们将按照它们第一次遇到的顺序附加到输出更改集的末尾。

如果发生错误,则返回SQLite错误代码,并将输出变量(* pnData)和(* ppData)设置为0.否则,将返回SQLITE_OK,并将输出变量设置为输出的大小并指向输出缓冲区,分别。在这种情况下,调用者有责任通过调用sqlite3_free()来释放缓冲区。

将更改集应用于数据库

int sqlite3changeset_apply( sqlite3 *db, /* Apply change to "main" db of this handle */ int nChangeset, /* Size of changeset in bytes */ void *pChangeset, /* Changeset blob */ int(*xFilter)( void *pCtx, /* Copy of sixth arg to _apply() */ const char *zTab /* Table name */ ), int(*xConflict)( void *pCtx, /* Copy of sixth arg to _apply() */ int eConflict, /* DATA, MISSING, CONFLICT, CONSTRAINT */ sqlite3_changeset_iter *p /* Handle describing change and conflict */ ), void *pCtx /* First argument passed to xConflict */

将更改集应用于数据库。此函数尝试更新附加到处理db的“main”数据库,并使用通过第二个和第三个参数传递的更改集中的更改。

传递给该函数的第四个参数(xFilter)是“过滤器回调”。如果它不是NULL,那么对于受变更集中至少一次更改影响的每个表,将使用表名称作为第二个参数调用过滤器回调,并将作为该函数的第六个参数传递的上下文指针的副本作为首先。如果“过滤器回调”返回零,则不会尝试对表格应用任何更改。否则,如果返回值非零或此函数的xFilter参数为NULL,则尝试所有与该表有关的更改。

对于未被过滤器回调排除的每个表,此函数测试目标数据库是否包含兼容表。如果满足以下所有条件,则表格被认为是兼容的:

  • 该表与变更集中记录的名称相同,并且

  • 该表至少具有与变更集中记录的列数一样多的列

  • 该表的主键列与变更集中记录的位置相同。

如果没有兼容的表,这不是一个错误,但是没有与表相关的更改被应用。通过sqlite3_log()机制发出警告消息,错误代码为SQLITE_SCHEMA。对变更集中的每个表最多发出一个此类警告。

对于每个有兼容表的更改,都会尝试根据UPDATE,INSERT或DELETE更改来修改表内容。如果更改不能被干净地应用,则可以调用作为sqlite3changeset_apply()的第五个参数传递的冲突处理函数。下面是关于何时为每种类型的更改调用冲突处理程序的描述。

与xFilter参数不同,xConflict可能不会传递NULL。将有效函数指针之外的其他任何内容作为xConflict参数传递的结果都是未定义的。

每次调用冲突处理函数时,都必须返回SQLITE_CHANGESET_OMIT,SQLITE_CHANGESET_ABORT或SQLITE_CHANGESET_REPLACE中的一个。如果传递给冲突处理程序的第二个参数是SQLITE_CHANGESET_DATA或SQLITE_CHANGESET_CONFLICT,则只能返回SQLITE_CHANGESET_REPLACE。如果冲突处理程序返回非法值,则任何已做出的更改都会回滚,并且对sqlite3changeset_apply()的调用返回SQLITE_MISUSE。sqlite3changeset_apply()根据每次调用冲突处理程序函数返回的值采取不同的操作。有关详细信息,请参阅文档以获取三种可用的返回值。

DELETE更改对于每个DELETE更改,此函数会检查目标数据库是否包含具有与存储在变更集中的原始行值相同的主键值(或多个值)的行。如果存在,并且存储在所有非主键列中的值也与存储在变更集中的值相匹配,则将从目标数据库中删除该行。

如果找到具有匹配主键值的行,但一个或多个非主键字段包含与存储在变更集中的原始行值不同的值,则使用SQLITE_CHANGESET_DATA作为第二个参数调用冲突处理函数。如果数据库表的列数多于变更集中记录的列数,则只会将这些非主键字段的值与当前数据库内容进行比较 - 任何尾随数据库表列都会被忽略。

如果在数据库中没有找到具有匹配主键值的行,则使用作为第二个参数传递的SQLITE_CHANGESET_NOTFOUND调用冲突处理函数。

If the DELETE operation is attempted, but SQLite returns SQLITE_CONSTRAINT (which can only happen if a foreign key constraint is violated), the conflict-handler function is invoked with SQLITE_CHANGESET_CONSTRAINT passed as the second argument. This includes the case where the DELETE operation is attempted because an earlier call to the conflict handler function returned SQLITE_CHANGESET_REPLACE.

INSERT Changes For each INSERT change, an attempt is made to insert the new row into the database. If the changeset row contains fewer fields than the database table, the trailing fields are populated with their default values.

If the attempt to insert the row fails because the database already contains a row with the same primary key values, the conflict handler function is invoked with the second argument set to SQLITE_CHANGESET_CONFLICT.

If the attempt to insert the row fails because of some other constraint violation (e.g. NOT NULL or UNIQUE), the conflict handler function is invoked with the second argument set to SQLITE_CHANGESET_CONSTRAINT. This includes the case where the INSERT operation is re-attempted because an earlier call to the conflict handler function returned SQLITE_CHANGESET_REPLACE.

UPDATE Changes For each UPDATE change, this function checks if the target database contains a row with the same primary key value (or values) as the original row values stored in the changeset. If it does, and the values stored in all modified non-primary key columns also match the values stored in the changeset the row is updated within the target database.

If a row with matching primary key values is found, but one or more of the modified non-primary key fields contains a value different from an original row value stored in the changeset, the conflict-handler function is invoked with SQLITE_CHANGESET_DATA as the second argument. Since UPDATE changes only contain values for non-primary key fields that are to be modified, only those fields need to match the original values to avoid the SQLITE_CHANGESET_DATA conflict-handler callback.

If no row with matching primary key values is found in the database, the conflict-handler function is invoked with SQLITE_CHANGESET_NOTFOUND passed as the second argument.

If the UPDATE operation is attempted, but SQLite returns SQLITE_CONSTRAINT, the conflict-handler function is invoked with SQLITE_CHANGESET_CONSTRAINT passed as the second argument. This includes the case where the UPDATE operation is attempted after an earlier call to the conflict handler function returned SQLITE_CHANGESET_REPLACE.

It is safe to execute SQL statements, including those that write to the table that the callback related to, from within the xConflict callback. This can be used to further customize the applications conflict resolution strategy.

All changes made by this function are enclosed in a savepoint transaction. If any other error (aside from a constraint failure when attempting to write to the target database) occurs, then the savepoint transaction is rolled back, restoring the target database to its original state, and an SQLite error code returned.

Concatenate Two Changeset Objects

int sqlite3changeset_concat( int nA, /* Number of bytes in buffer pA */ void *pA, /* Pointer to buffer containing changeset A */ int nB, /* Number of bytes in buffer pB */ void *pB, /* Pointer to buffer containing changeset B */ int *pnOut, /* OUT: Number of bytes in output changeset */ void **ppOut /* OUT: Buffer containing output changeset */

This function is used to concatenate two changesets, A and B, into a single changeset. The result is a changeset equivalent to applying changeset A followed by changeset B.

This function combines the two input changesets using an sqlite3_changegroup object. Calling it produces similar results as the following code fragment:

sqlite3_changegroup *pGrp; rc = sqlite3_changegroup_new(&pGrp if( rc==SQLITE_OK ) rc = sqlite3changegroup_add(pGrp, nA, pA if( rc==SQLITE_OK ) rc = sqlite3changegroup_add(pGrp, nB, pB if( rc==SQLITE_OK ){ rc = sqlite3changegroup_output(pGrp, pnOut, ppOut }else{ *ppOut = 0; *pnOut = 0; }

Refer to the sqlite3_changegroup documentation below for details.

Obtain Conflicting Row Values From A Changeset Iterator

int sqlite3changeset_conflict( sqlite3_changeset_iter *pIter, /* Changeset iterator */ int iVal, /* Column number */ sqlite3_value **ppValue /* OUT: Value from conflicting row */

This function should only be used with iterator objects passed to a conflict-handler callback by sqlite3changeset_apply() with either SQLITE_CHANGESET_DATA or SQLITE_CHANGESET_CONFLICT. If this function is called on any other iterator, SQLITE_MISUSE is returned and *ppValue is set to NULL.

Argument iVal must be greater than or equal to 0, and less than the number of columns in the table affected by the current change. Otherwise, SQLITE_RANGE is returned and *ppValue is set to NULL.

If successful, this function sets *ppValue to point to a protected sqlite3_value object containing the iVal'th value from the "conflicting row" associated with the current conflict-handler callback and returns SQLITE_OK.

If some other error occurs (e.g. an OOM condition), an SQLite error code is returned and *ppValue is set to NULL.

Finalize A Changeset Iterator

int sqlite3changeset_finalize(sqlite3_changeset_iter *pIter

This function is used to finalize an iterator allocated with sqlite3changeset_start().

This function should only be called on iterators created using the sqlite3changeset_start() function. If an application calls this function with an iterator passed to a conflict-handler by sqlite3changeset_apply(), SQLITE_MISUSE is immediately returned and the call has no effect.

If an error was encountered within a call to an sqlite3changeset_xxx() function (for example an SQLITE_CORRUPT in sqlite3changeset_next() or an SQLITE_NOMEM in sqlite3changeset_new()) then an error code corresponding to that error is returned by this function. Otherwise, SQLITE_OK is returned. This is to allow the following pattern (pseudo-code):

sqlite3changeset_start( while( SQLITE_ROW==sqlite3changeset_next() ){ // Do something with change. } rc = sqlite3changeset_finalize( if( rc!=SQLITE_OK ){ // An error has occurred }

Determine The Number Of Foreign Key Constraint Violations

int sqlite3changeset_fk_conflicts( sqlite3_changeset_iter *pIter, /* Changeset iterator */ int *pnOut /* OUT: Number of FK violations */

This function may only be called with an iterator passed to an SQLITE_CHANGESET_FOREIGN_KEY conflict handler callback. In this case it sets the output variable to the total number of known foreign key violations in the destination database and returns SQLITE_OK.

In all other cases this function returns SQLITE_MISUSE.

Invert A Changeset

int sqlite3changeset_invert( int nIn, const void *pIn, /* Input changeset */ int *pnOut, void **ppOut /* OUT: Inverse of input */

This function is used to "invert" a changeset object. Applying an inverted changeset to a database reverses the effects of applying the uninverted changeset. Specifically:

  • Each DELETE change is changed to an INSERT, and

  • Each INSERT change is changed to a DELETE, and

  • For each UPDATE change, the old.* and new.* values are exchanged.

This function does not change the order in which changes appear within the changeset. It merely reverses the sense of each individual change.

If successful, a pointer to a buffer containing the inverted changeset is stored in *ppOut, the size of the same buffer is stored in *pnOut, and SQLITE_OK is returned. If an error occurs, both *pnOut and *ppOut are zeroed and an SQLite error code returned.

It is the responsibility of the caller to eventually call sqlite3_free() on the *ppOut pointer to free the buffer allocation following a successful call to this function.

WARNING/TODO: This function currently assumes that the input is a valid changeset. If it is not, the results are undefined.

Obtain new.* Values From A Changeset Iterator

int sqlite3changeset_new( sqlite3_changeset_iter *pIter, /* Changeset iterator */ int iVal, /* Column number */ sqlite3_value **ppValue /* OUT: New value (or NULL pointer) */

The pIter argument passed to this function may either be an iterator passed to a conflict-handler by sqlite3changeset_apply(), or an iterator created by sqlite3changeset_start(). In the latter case, the most recent call to sqlite3changeset_next() must have returned SQLITE_ROW. Furthermore, it may only be called if the type of change that the iterator currently points to is either SQLITE_UPDATE or SQLITE_INSERT. Otherwise, this function returns SQLITE_MISUSE and sets *ppValue to NULL.

Argument iVal must be greater than or equal to 0, and less than the number of columns in the table affected by the current change. Otherwise, SQLITE_RANGE is returned and *ppValue is set to NULL.

If successful, this function sets *ppValue to point to a protected sqlite3_value object containing the iVal'th value from the vector of new row values stored as part of the UPDATE or INSERT change and returns SQLITE_OK. If the change is an UPDATE and does not include a new value for the requested column, *ppValue is set to NULL and SQLITE_OK returned. The name of the function comes from the fact that this is similar to the "new.*" columns available to update or delete triggers.

If some other error occurs (e.g. an OOM condition), an SQLite error code is returned and *ppValue is set to NULL.

Advance A Changeset Iterator

int sqlite3changeset_next(sqlite3_changeset_iter *pIter

This function may only be used with iterators created by function sqlite3changeset_start(). If it is called on an iterator passed to a conflict-handler callback by sqlite3changeset_apply(), SQLITE_MISUSE is returned and the call has no effect.

Immediately after an iterator is created by sqlite3changeset_start(), it does not point to any change in the changeset. Assuming the changeset is not empty, the first call to this function advances the iterator to point to the first change in the changeset. Each subsequent call advances the iterator to point to the next change in the changeset (if any). If no error occurs and the iterator points to a valid change after a call to sqlite3changeset_next() has advanced it, SQLITE_ROW is returned. Otherwise, if all changes in the changeset have already been visited, SQLITE_DONE is returned.

If an error occurs, an SQLite error code is returned. Possible error codes include SQLITE_CORRUPT (if the changeset buffer is corrupt) or SQLITE_NOMEM.

Obtain old.* Values From A Changeset Iterator

int sqlite3changeset_old( sqlite3_changeset_iter *pIter, /* Changeset iterator */ int iVal, /* Column number */ sqlite3_value **ppValue /* OUT: Old value (or NULL pointer) */

The pIter argument passed to this function may either be an iterator passed to a conflict-handler by sqlite3changeset_apply(), or an iterator created by sqlite3changeset_start(). In the latter case, the most recent call to sqlite3changeset_next() must have returned SQLITE_ROW. Furthermore, it may only be called if the type of change that the iterator currently points to is either SQLITE_DELETE or SQLITE_UPDATE. Otherwise, this function returns SQLITE_MISUSE and sets *ppValue to NULL.

Argument iVal must be greater than or equal to 0, and less than the number of columns in the table affected by the current change. Otherwise, SQLITE_RANGE is returned and *ppValue is set to NULL.

If successful, this function sets *ppValue to point to a protected sqlite3_value object containing the iVal'th value from the vector of original row values stored as part of the UPDATE or DELETE change and returns SQLITE_OK. The name of the function comes from the fact that this is similar to the "old.*" columns available to update or delete triggers.

If some other error occurs (e.g. an OOM condition), an SQLite error code is returned and *ppValue is set to NULL.

Obtain The Current Operation From A Changeset Iterator

int sqlite3changeset_op( sqlite3_changeset_iter *pIter, /* Iterator object */ const char **pzTab, /* OUT: Pointer to table name */ int *pnCol, /* OUT: Number of columns in table */ int *pOp, /* OUT: SQLITE_INSERT, DELETE or UPDATE */ int *pbIndirect /* OUT: True for an 'indirect' change */

The pIter argument passed to this function may either be an iterator passed to a conflict-handler by sqlite3changeset_apply(), or an iterator created by sqlite3changeset_start(). In the latter case, the most recent call to sqlite3changeset_next() must have returned SQLITE_ROW. If this is not the case, this function returns SQLITE_MISUSE.

If argument pzTab is not NULL, then *pzTab is set to point to a nul-terminated utf-8 encoded string containing the name of the table affected by the current change. The buffer remains valid until either sqlite3changeset_next() is called on the iterator or until the conflict-handler function returns. If pnCol is not NULL, then *pnCol is set to the number of columns in the table affected by the change. If pbIncorrect is not NULL, then *pbIndirect is set to true (1) if the change is an indirect change, or false (0) otherwise. See the documentation for sqlite3session_indirect() for a description of direct and indirect changes. Finally, if pOp is not NULL, then *pOp is set to one of SQLITE_INSERT, SQLITE_DELETE or SQLITE_UPDATE, depending on the type of change that the iterator currently points to.

If no error occurs, SQLITE_OK is returned. If an error does occur, an SQLite error code is returned. The values of the output variables may not be trusted in this case.

Obtain The Primary Key Definition Of A Table

int sqlite3changeset_pk( sqlite3_changeset_iter *pIter, /* Iterator object */ unsigned char **pabPK, /* OUT: Array of boolean - true for PK cols */ int *pnCol /* OUT: Number of entries in output array */

For each modified table, a changeset includes the following:

  • The number of columns in the table, and

  • Which of those columns make up the tables PRIMARY KEY.

This function is used to find which columns comprise the PRIMARY KEY of the table modified by the change that iterator pIter currently points to. If successful, *pabPK is set to point to an array of nCol entries, where nCol is the number of columns in the table. Elements of *pabPK are set to 0x01 if the corresponding column is part of the tables primary key, or 0x00 if it is not.

If argument pnCol is not NULL, then *pnCol is set to the number of columns in the table.

If this function is called when the iterator does not point to a valid entry, SQLITE_MISUSE is returned and the output variables zeroed. Otherwise, SQLITE_OK is returned and the output variables populated as described above.

Create An Iterator To Traverse A Changeset

int sqlite3changeset_start( sqlite3_changeset_iter **pp, /* OUT: New changeset iterator handle */ int nChangeset, /* Size of changeset blob in bytes */ void *pChangeset /* Pointer to blob containing changeset */

Create an iterator used to iterate through the contents of a changeset. If successful, *pp is set to point to the iterator handle and SQLITE_OK is returned. Otherwise, if an error occurs, *pp is set to zero and an SQLite error code is returned.

The following functions can be used to advance and query a changeset iterator created by this function:

  • sqlite3changeset_next()

  • sqlite3changeset_op()

  • sqlite3changeset_new()

  • sqlite3changeset_old()

It is the responsibility of the caller to eventually destroy the iterator by passing it to sqlite3changeset_finalize(). The buffer containing the changeset (pChangeset) must remain valid until after the iterator is destroyed.

Assuming the changeset blob was created by one of the sqlite3session_changeset(), sqlite3changeset_concat() or sqlite3changeset_invert() functions, all changes within the changeset that apply to a single table are grouped together. This means that when an application iterates through a changeset using an iterator created by this function, all changes that relate to a single table are visited consecutively. There is no chance that the iterator will visit a change the applies to table X, then one for table Y, and then later on visit another change for table X.

Attach A Table To A Session Object

int sqlite3session_attach( sqlite3_session *pSession, /* Session object */ const char *zTab /* Table name */

If argument zTab is not NULL, then it is the name of a table to attach to the session object passed as the first argument. All subsequent changes made to the table while the session object is enabled will be recorded. See documentation for sqlite3session_changeset() for further details.

Or, if argument zTab is NULL, then changes are recorded for all tables in the database. If additional tables are added to the database (by executing "CREATE TABLE" statements) after this call is made, changes for the new tables are also recorded.

Changes can only be recorded for tables that have a PRIMARY KEY explicitly defined as part of their CREATE TABLE statement. It does not matter if the PRIMARY KEY is an "INTEGER PRIMARY KEY" (rowid alias) or not. The PRIMARY KEY may consist of a single column, or may be a composite key.

It is not an error if the named table does not exist in the database. Nor is it an error if the named table does not have a PRIMARY KEY. However, no changes will be recorded in either of these scenarios.

Changes are not recorded for individual rows that have NULL values stored in one or more of their PRIMARY KEY columns.

SQLITE_OK is returned if the call completes without error. Or, if an error occurs, an SQLite error code (e.g. SQLITE_NOMEM) is returned.

Generate A Changeset From A Session Object

int sqlite3session_changeset( sqlite3_session *pSession, /* Session object */ int *pnChangeset, /* OUT: Size of buffer at *ppChangeset */ void **ppChangeset /* OUT: Buffer containing changeset */

Obtain a changeset containing changes to the tables attached to the session object passed as the first argument. If successful, set *ppChangeset to point to a buffer containing the changeset and *pnChangeset to the size of the changeset in bytes before returning SQLITE_OK. If an error occurs, set both *ppChangeset and *pnChangeset to zero and return an SQLite error code.

A changeset consists of zero or more INSERT, UPDATE and/or DELETE changes, each representing a change to a single row of an attached table. An INSERT change contains the values of each field of a new database row. A DELETE contains the original values of each field of a deleted database row. An UPDATE change contains the original values of each field of an updated database row along with the updated values for each updated non-primary-key column. It is not possible for an UPDATE change to represent a change that modifies the values of primary key columns. If such a change is made, it is represented in a changeset as a DELETE followed by an INSERT.

Changes are not recorded for rows that have NULL values stored in one or more of their PRIMARY KEY columns. If such a row is inserted or deleted, no corresponding change is present in the changesets returned by this function. If an existing row with one or more NULL values stored in PRIMARY KEY columns is updated so that all PRIMARY KEY columns are non-NULL, only an INSERT is appears in the changeset. Similarly, if an existing row with non-NULL PRIMARY KEY values is updated so that one or more of its PRIMARY KEY columns are set to NULL, the resulting changeset contains a DELETE change only.

The contents of a changeset may be traversed using an iterator created using the sqlite3changeset_start() API. A changeset may be applied to a database with a compatible schema using the sqlite3changeset_apply() API.

Within a changeset generated by this function, all changes related to a single table are grouped together. In other words, when iterating through a changeset or when applying a changeset to a database, all changes related to a single table are processed before moving on to the next table. Tables are sorted in the same order in which they were attached (or auto-attached) to the sqlite3_session object. The order in which the changes related to a single table are stored is undefined.

Following a successful call to this function, it is the responsibility of the caller to eventually free the buffer that *ppChangeset points to using sqlite3_free().

Changeset Generation

Once a table has been attached to a session object, the session object records the primary key values of all new rows inserted into the table. It also records the original primary key and other column values of any deleted or updated rows. For each unique primary key value, data is only recorded once - the first time a row with said primary key is inserted, updated or deleted in the lifetime of the session.

There is one exception to the previous paragraph: when a row is inserted, updated or deleted, if one or more of its primary key columns contain a NULL value, no record of the change is made.

The session object therefore accumulates two types of records - those that consist of primary key values only (created when the user inserts a new record) and those that consist of the primary key values and the original values of other table columns (created when the users deletes or updates a record).

When this function is called, the requested changeset is created using both the accumulated records and the current contents of the database file. Specifically:

  • For each record generated by an insert, the database is queried for a row with a matching primary key. If one is found, an INSERT change is added to the changeset. If no such row is found, no change is added to the changeset.

  • For each record generated by an update or delete, the database is queried for a row with a matching primary key. If such a row is found and one or more of the non-primary key fields have been modified from their original values, an UPDATE change is added to the changeset. Or, if no such row is found in the table, a DELETE change is added to the changeset. If there is a row with a matching primary key in the database, but all fields contain their original values, no change is added to the changeset.

This means, amongst other things, that if a row is inserted and then later deleted while a session object is active, neither the insert nor the delete will be present in the changeset. Or if a row is deleted and then later a row with the same primary key values inserted while a session object is active, the resulting changeset will contain an UPDATE change instead of a DELETE and an INSERT.

When a session object is disabled (see the sqlite3session_enable() API), it does not accumulate records when rows are inserted, updated or deleted. This may appear to have some counter-intuitive effects if a single row is written to more than once during a session. For example, if a row is inserted while a session object is enabled, then later deleted while the same session object is disabled, no INSERT record will appear in the changeset, even though the delete took place while the session was disabled. Or, if one field of a row is updated while a session is disabled, and another field of the same row is updated while the session is enabled, the resulting changeset will contain an UPDATE change that updates both fields.

Create A New Session Object

int sqlite3session_create( sqlite3 *db, /* Database handle */ const char *zDb, /* Name of db (e.g. "main") */ sqlite3_session **ppSession /* OUT: New session object */

Create a new session object attached to database handle db. If successful, a pointer to the new object is written to *ppSession and SQLITE_OK is returned. If an error occurs, *ppSession is set to NULL and an SQLite error code (e.g. SQLITE_NOMEM) is returned.

It is possible to create multiple session objects attached to a single database handle.

Session objects created using this function should be deleted using the sqlite3session_delete() function before the database handle that they are attached to is itself closed. If the database handle is closed before the session object is deleted, then the results of calling any session module function, including sqlite3session_delete() on the session object are undefined.

Because the session module uses the sqlite3_preupdate_hook() API, it is not possible for an application to register a pre-update hook on a database handle that has one or more session objects attached. Nor is it possible to create a session object attached to a database handle for which a pre-update hook is already defined. The results of attempting either of these things are undefined.

The session object will be used to create changesets for tables in database zDb, where zDb is either "main", or "temp", or the name of an attached database. It is not an error if database zDb is not attached to the database when the session object is created.

Delete A Session Object

void sqlite3session_delete(sqlite3_session *pSession

Delete a session object previously allocated using sqlite3session_create(). Once a session object has been deleted, the results of attempting to use pSession with any other session module function are undefined.

Session objects must be deleted before the database handle to which they are attached is closed. Refer to the documentation for sqlite3session_create() for details.

Load The Difference Between Tables Into A Session

int sqlite3session_diff( sqlite3_session *pSession, const char *zFromDb, const char *zTbl, char **pzErrMsg

If it is not already attached to the session object passed as the first argument, this function attaches table zTbl in the same manner as the sqlite3session_attach() function. If zTbl does not exist, or if it does not have a primary key, this function is a no-op (but does not return an error).

Argument zFromDb must be the name of a database ("main", "temp" etc.) attached to the same database handle as the session object that contains a table compatible with the table attached to the session by this function. A table is considered compatible if it:

  • Has the same name,

  • Has the same set of columns declared in the same order, and

  • Has the same PRIMARY KEY definition.

If the tables are not compatible, SQLITE_SCHEMA is returned. If the tables are compatible but do not have any PRIMARY KEY columns, it is not an error but no changes are added to the session object. As with other session APIs, tables without PRIMARY KEYs are simply ignored.

This function adds a set of changes to the session object that could be used to update the table in database zFrom (call this the "from-table") so that its content is the same as the table attached to the session object (call this the "to-table"). Specifically:

  • For each row (primary key) that exists in the to-table but not in the from-table, an INSERT record is added to the session object.

  • For each row (primary key) that exists in the to-table but not in the from-table, a DELETE record is added to the session object.

  • For each row (primary key) that exists in both tables, but features different non-PK values in each, an UPDATE record is added to the session.

To clarify, if this function is called and then a changeset constructed using sqlite3session_changeset(), then after applying that changeset to database zFrom the contents of the two compatible tables would be identical.

It an error if database zFrom does not exist or does not contain the required compatible table.

If the operation successful, SQLITE_OK is returned. Otherwise, an SQLite error code. In this case, if argument pzErrMsg is not NULL, *pzErrMsg may be set to point to a buffer containing an English language error message. It is the responsibility of the caller to free this buffer using sqlite3_free().

Enable Or Disable A Session Object

int sqlite3session_enable(sqlite3_session *pSession, int bEnable

Enable or disable the recording of changes by a session object. When enabled, a session object records changes made to the database. When disabled - it does not. A newly created session object is enabled. Refer to the documentation for sqlite3session_changeset() for further details regarding how enabling and disabling a session object affects the eventual changesets.

Passing zero to this function disables the session. Passing a value greater than zero enables it. Passing a value less than zero is a no-op, and may be used to query the current state of the session.

The return value indicates the final state of the session object: 0 if the session is disabled, or 1 if it is enabled.

Set Or Clear the Indirect Change Flag

int sqlite3session_indirect(sqlite3_session *pSession, int bIndirect

Each change recorded by a session object is marked as either direct or indirect. A change is marked as indirect if either:

  • The session object "indirect" flag is set when the change is made, or

  • The change is made by an SQL trigger or foreign key action instead of directly as a result of a users SQL statement.

If a single row is affected by more than one operation within a session, then the change is considered indirect if all operations meet the criteria for an indirect change above, or direct otherwise.

This function is used to set, clear or query the session object indirect flag. If the second argument passed to this function is zero, then the indirect flag is cleared. If it is greater than zero, the indirect flag is set. Passing a value less than zero does not modify the current value of the indirect flag, and may be used to query the current state of the indirect flag for the specified session object.

The return value indicates the final state of the indirect flag: 0 if it is clear, or 1 if it is set.

Test if a changeset has recorded any changes.

int sqlite3session_isempty(sqlite3_session *pSession

Return non-zero if no changes to attached tables have been recorded by the session object passed as the first argument. Otherwise, if one or more changes have been recorded, return zero.

Even if this function returns zero, it is possible that calling sqlite3session_changeset() on the session handle may still return a changeset that contains no changes. This can happen when a row in an attached table is modified and then later on the original values are restored. However, if this function returns non-zero, then it is guaranteed that a call to sqlite3session_changeset() will return a changeset containing zero changes.

Generate A Patchset From A Session Object

int sqlite3session_patchset( sqlite3_session *pSession, /* Session object */ int *pnPatchset, /* OUT: Size of buffer at *ppPatchset */ void **ppPatchset /* OUT: Buffer containing patchset */

The differences between a patchset and a changeset are that:

  • DELETE records consist of the primary key fields only. The original values of other fields are omitted.

  • The original values of any modified fields are omitted from UPDATE records.

A patchset blob may be used with up to date versions of all sqlite3changeset_xxx API functions except for sqlite3changeset_invert(), which returns SQLITE_CORRUPT if it is passed a patchset. Similarly, attempting to use a patchset blob with old versions of the sqlite3changeset_xxx APIs also provokes an SQLITE_CORRUPT error.

Because the non-primary key "old.*" fields are omitted, no SQLITE_CHANGESET_DATA conflicts can be detected or reported if a patchset is passed to the sqlite3changeset_apply() API. Other conflict types work in the same way as for changesets.

Changes within a patchset are ordered in the same way as for changesets generated by the sqlite3session_changeset() function (i.e. all changes for a single table are grouped together, tables appear in the order in which they were attached to the session object).

Set a table filter on a Session Object.

void sqlite3session_table_filter( sqlite3_session *pSession, /* Session object */ int(*xFilter)( void *pCtx, /* Copy of third arg to _filter_table() */ const char *zTab /* Table name */ ), void *pCtx /* First argument passed to xFilter */

The second argument (xFilter) is the "filter callback". For changes to rows in tables that are not attached to the Session object, the filter is called to determine whether changes to the table's rows should be tracked or not. If xFilter returns 0, changes is not tracked. Note that once a table is attached, xFilter will not be called again.

Constants Returned By The Conflict Handler

#define SQLITE_CHANGESET_OMIT 0 #define SQLITE_CHANGESET_REPLACE 1 #define SQLITE_CHANGESET_ABORT 2

A conflict handler callback must return one of the following three values.

SQLITE_CHANGESET_OMIT If a conflict handler returns this value no special action is taken. The change that caused the conflict is not applied. The session module continues to the next change in the changeset. SQLITE_CHANGESET_REPLACE This value may only be returned if the second argument to the conflict handler was SQLITE_CHANGESET_DATA or SQLITE_CHANGESET_CONFLICT. If this is not the case, any changes applied so far are rolled back and the call to sqlite3changeset_apply() returns SQLITE_MISUSE.

If CHANGESET_REPLACE is returned by an SQLITE_CHANGESET_DATA conflict handler, then the conflicting row is either updated or deleted, depending on the type of change.

If CHANGESET_REPLACE is returned by an SQLITE_CHANGESET_CONFLICT conflict handler, then the conflicting row is removed from the database and a second attempt to apply the change is made. If this second attempt fails, the original row is restored to the database before continuing.

SQLITE_CHANGESET_ABORT If this value is returned, any changes applied so far are rolled back and the call to sqlite3changeset_apply() returns SQLITE_ABORT.

Constants Passed To The Conflict Handler

#define SQLITE_CHANGESET_DATA 1 #define SQLITE_CHANGESET_NOTFOUND 2 #define SQLITE_CHANGESET_CONFLICT 3 #define SQLITE_CHANGESET_CONSTRAINT 4 #define SQLITE_CHANGESET_FOREIGN_KEY 5

Values that may be passed as the second argument to a conflict-handler.

SQLITE_CHANGESET_DATA The conflict handler is invoked with CHANGESET_DATA as the second argument when processing a DELETE or UPDATE change if a row with the required PRIMARY KEY fields is present in the database, but one or more other (non primary-key) fields modified by the update do not contain the expected "before" values.

The conflicting row, in this case, is the database row with the matching primary key.

SQLITE_CHANGESET_NOTFOUND The conflict handler is invoked with CHANGESET_NOTFOUND as the second argument when processing a DELETE or UPDATE change if a row with the required PRIMARY KEY fields is not present in the database.

There is no conflicting row in this case. The results of invoking the sqlite3changeset_conflict() API are undefined.

SQLITE_CHANGESET_CONFLICT CHANGESET_CONFLICT is passed as the second argument to the conflict handler while processing an INSERT change if the operation would result in duplicate primary key values.

The conflicting row in this case is the database row with the matching primary key.

SQLITE_CHANGESET_FOREIGN_KEY If foreign key handling is enabled, and applying a changeset leaves the database in a state containing foreign key violations, the conflict handler is invoked with CHANGESET_FOREIGN_KEY as the second argument exactly once before the changeset is committed. If the conflict handler returns CHANGESET_OMIT, the changes, including those that caused the foreign key constraint violation, are committed. Or, if it returns CHANGESET_ABORT, the changeset is rolled back.

No current or conflicting row information is provided. The only function it is possible to call on the supplied sqlite3_changeset_iter handle is sqlite3changeset_fk_conflicts().

SQLITE_CHANGESET_CONSTRAINT If any other constraint violation occurs while applying a change (i.e. a UNIQUE, CHECK or NOT NULL constraint), the conflict handler is invoked with CHANGESET_CONSTRAINT as the second argument.

There is no conflicting row in this case. The results of invoking the sqlite3changeset_conflict() API are undefined.

Streaming Versions of API functions.

int sqlite3changeset_apply_strm( sqlite3 *db, /* Apply change to "main" db of this handle */ int (*xInput)(void *pIn, void *pData, int *pnData), /* Input function */ void *pIn, /* First arg for xInput */ int(*xFilter)( void *pCtx, /* Copy of sixth arg to _apply() */ const char *zTab /* Table name */ ), int(*xConflict)( void *pCtx, /* Copy of sixth arg to _apply() */ int eConflict, /* DATA, MISSING, CONFLICT, CONSTRAINT */ sqlite3_changeset_iter *p /* Handle describing change and conflict */ ), void *pCtx /* First argument passed to xConflict */ int sqlite3changeset_concat_strm( int (*xInputA)(void *pIn, void *pData, int *pnData), void *pInA, int (*xInputB)(void *pIn, void *pData, int *pnData), void *pInB, int (*xOutput)(void *pOut, const void *pData, int nData), void *pOut int sqlite3changeset_invert_strm( int (*xInput)(void *pIn, void *pData, int *pnData), void *pIn, int (*xOutput)(void *pOut, const void *pData, int nData), void *pOut int sqlite3changeset_start_strm( sqlite3_changeset_iter **pp, int (*xInput)(void *pIn, void *pData, int *pnData), void *pIn int sqlite3session_changeset_strm( sqlite3_session *pSession, int (*xOutput)(void *pOut, const void *pData, int nData), void *pOut int sqlite3session_patchset_strm( sqlite3_session *pSession, int (*xOutput)(void *pOut, const void *pData, int nData), void *pOut int sqlite3changegroup_add_strm(sqlite3_changegroup*, int (*xInput)(void *pIn, void *pData, int *pnData), void *pIn int sqlite3changegroup_output_strm(sqlite3_changegroup*, int (*xOutput)(void *pOut, const void *pData, int nData), void *pOut

The six streaming API xxx_strm() functions serve similar purposes to the corresponding non-streaming API functions:

Streaming functionNon-streaming equivalent
sqlite3changeset_apply_strmsqlite3changeset_apply
sqlite3changeset_concat_strmsqlite3changeset_concat
sqlite3changeset_invert_strmsqlite3changeset_invert
sqlite3changeset_start_strmsqlite3changeset_start
sqlite3session_changeset_strmsqlite3session_changeset
sqlite3session_patchset_strmsqlite3session_patchset

Non-streaming functions that accept changesets (or patchsets) as input require that the entire changeset be stored in a single buffer in memory. Similarly, those that return a changeset or patchset do so by returning a pointer to a single large buffer allocated using sqlite3_malloc(). Normally this is convenient. However, if an application running in a low-memory environment is required to handle very large changesets, the large contiguous memory allocations required can become onerous.

In order to avoid this problem, instead of a single large buffer, input is passed to a streaming API functions by way of a callback function that the sessions module invokes to incrementally request input data as it is required. In all cases, a pair of API function parameters such as

  int nChangeset,   void *pChangeset,

Is replaced by:

  int (*xInput)(void *pIn, void *pData, int *pnData),   void *pIn,

Each time the xInput callback is invoked by the sessions module, the first argument passed is a copy of the supplied pIn context pointer. The second argument, pData, points to a buffer (*pnData) bytes in size. Assuming no error occurs the xInput method should copy up to (*pnData) bytes of data into the buffer and set (*pnData) to the actual number of bytes copied before returning SQLITE_OK. If the input is completely exhausted, (*pnData) should be set to zero to indicate this. Or, if an error occurs, an SQLite error code should be returned. In all cases, if an xInput callback returns an error, all processing is abandoned and the streaming API function returns a copy of the error code to the caller.

In the case of sqlite3changeset_start_strm(), the xInput callback may be invoked by the sessions module at any point during the lifetime of the iterator. If such an xInput callback returns an error, the iterator enters an error state, whereby all subsequent calls to iterator functions immediately fail with the same error code as returned by xInput.

Similarly, streaming API functions that return changesets (or patchsets) return them in chunks by way of a callback function instead of via a pointer to a single large buffer. In this case, a pair of parameters such as:

  int *pnChangeset,   void **ppChangeset,

Is replaced by:

  int (*xOutput)(void *pOut, const void *pData, int nData),   void *pOut

The xOutput callback is invoked zero or more times to return data to the application. The first parameter passed to each call is a copy of the pOut pointer supplied by the application. The second parameter, pData, points to a buffer nData bytes in size containing the chunk of output data being returned. If the xOutput callback successfully processes the supplied data, it should return SQLITE_OK to indicate success. Otherwise, it should return some other SQLite error code. In this case processing is immediately abandoned and the streaming API function returns a copy of the xOutput error code to the application.

The sessions module never invokes an xOutput callback with the third parameter set to a value less than or equal to zero. Other than this, no guarantees are made as to the size of the chunks of data returned.

SQLite is in the Public Domain.

https://sqlite.org/session.html