End-of-line whitespace cleanups and doc typo fixes. No code changes.
FossilOrigin-Name: bdfd72a083fadd724030c4c89adae71426e1ddd402c6bc5abf40801ecf3253cf
This commit is contained in:
parent
3db12cd7c4
commit
0945197a39
@ -10,42 +10,42 @@
|
||||
**
|
||||
*************************************************************************
|
||||
**
|
||||
** This file contains the public interface for the RBU extension.
|
||||
** This file contains the public interface for the RBU extension.
|
||||
*/
|
||||
|
||||
/*
|
||||
** SUMMARY
|
||||
**
|
||||
** Writing a transaction containing a large number of operations on
|
||||
** Writing a transaction containing a large number of operations on
|
||||
** b-tree indexes that are collectively larger than the available cache
|
||||
** memory can be very inefficient.
|
||||
** memory can be very inefficient.
|
||||
**
|
||||
** The problem is that in order to update a b-tree, the leaf page (at least)
|
||||
** containing the entry being inserted or deleted must be modified. If the
|
||||
** working set of leaves is larger than the available cache memory, then a
|
||||
** single leaf that is modified more than once as part of the transaction
|
||||
** working set of leaves is larger than the available cache memory, then a
|
||||
** single leaf that is modified more than once as part of the transaction
|
||||
** may be loaded from or written to the persistent media multiple times.
|
||||
** Additionally, because the index updates are likely to be applied in
|
||||
** random order, access to pages within the database is also likely to be in
|
||||
** random order, access to pages within the database is also likely to be in
|
||||
** random order, which is itself quite inefficient.
|
||||
**
|
||||
** One way to improve the situation is to sort the operations on each index
|
||||
** by index key before applying them to the b-tree. This leads to an IO
|
||||
** pattern that resembles a single linear scan through the index b-tree,
|
||||
** and all but guarantees each modified leaf page is loaded and stored
|
||||
** and all but guarantees each modified leaf page is loaded and stored
|
||||
** exactly once. SQLite uses this trick to improve the performance of
|
||||
** CREATE INDEX commands. This extension allows it to be used to improve
|
||||
** the performance of large transactions on existing databases.
|
||||
**
|
||||
** Additionally, this extension allows the work involved in writing the
|
||||
** large transaction to be broken down into sub-transactions performed
|
||||
** sequentially by separate processes. This is useful if the system cannot
|
||||
** guarantee that a single update process will run for long enough to apply
|
||||
** the entire update, for example because the update is being applied on a
|
||||
** mobile device that is frequently rebooted. Even after the writer process
|
||||
** Additionally, this extension allows the work involved in writing the
|
||||
** large transaction to be broken down into sub-transactions performed
|
||||
** sequentially by separate processes. This is useful if the system cannot
|
||||
** guarantee that a single update process will run for long enough to apply
|
||||
** the entire update, for example because the update is being applied on a
|
||||
** mobile device that is frequently rebooted. Even after the writer process
|
||||
** has committed one or more sub-transactions, other database clients continue
|
||||
** to read from the original database snapshot. In other words, partially
|
||||
** applied transactions are not visible to other clients.
|
||||
** to read from the original database snapshot. In other words, partially
|
||||
** applied transactions are not visible to other clients.
|
||||
**
|
||||
** "RBU" stands for "Resumable Bulk Update". As in a large database update
|
||||
** transmitted via a wireless network to a mobile device. A transaction
|
||||
@ -61,9 +61,9 @@
|
||||
**
|
||||
** * INSERT statements may not use any default values.
|
||||
**
|
||||
** * UPDATE and DELETE statements must identify their target rows by
|
||||
** * UPDATE and DELETE statements must identify their target rows by
|
||||
** non-NULL PRIMARY KEY values. Rows with NULL values stored in PRIMARY
|
||||
** KEY fields may not be updated or deleted. If the table being written
|
||||
** KEY fields may not be updated or deleted. If the table being written
|
||||
** has no PRIMARY KEY, affected rows must be identified by rowid.
|
||||
**
|
||||
** * UPDATE statements may not modify PRIMARY KEY columns.
|
||||
@ -80,10 +80,10 @@
|
||||
** PREPARATION
|
||||
**
|
||||
** An "RBU update" is stored as a separate SQLite database. A database
|
||||
** containing an RBU update is an "RBU database". For each table in the
|
||||
** containing an RBU update is an "RBU database". For each table in the
|
||||
** target database to be updated, the RBU database should contain a table
|
||||
** named "data_<target name>" containing the same set of columns as the
|
||||
** target table, and one more - "rbu_control". The data_% table should
|
||||
** target table, and one more - "rbu_control". The data_% table should
|
||||
** have no PRIMARY KEY or UNIQUE constraints, but each column should have
|
||||
** the same type as the corresponding column in the target database.
|
||||
** The "rbu_control" column should have no type at all. For example, if
|
||||
@ -98,22 +98,22 @@
|
||||
** The order of the columns in the data_% table does not matter.
|
||||
**
|
||||
** Instead of a regular table, the RBU database may also contain virtual
|
||||
** tables or view named using the data_<target> naming scheme.
|
||||
** tables or views named using the data_<target> naming scheme.
|
||||
**
|
||||
** Instead of the plain data_<target> naming scheme, RBU database tables
|
||||
** Instead of the plain data_<target> naming scheme, RBU database tables
|
||||
** may also be named data<integer>_<target>, where <integer> is any sequence
|
||||
** of zero or more numeric characters (0-9). This can be significant because
|
||||
** tables within the RBU database are always processed in order sorted by
|
||||
** tables within the RBU database are always processed in order sorted by
|
||||
** name. By judicious selection of the <integer> portion of the names
|
||||
** of the RBU tables the user can therefore control the order in which they
|
||||
** are processed. This can be useful, for example, to ensure that "external
|
||||
** content" FTS4 tables are updated before their underlying content tables.
|
||||
**
|
||||
** If the target database table is a virtual table or a table that has no
|
||||
** PRIMARY KEY declaration, the data_% table must also contain a column
|
||||
** named "rbu_rowid". This column is mapped to the tables implicit primary
|
||||
** key column - "rowid". Virtual tables for which the "rowid" column does
|
||||
** not function like a primary key value cannot be updated using RBU. For
|
||||
** PRIMARY KEY declaration, the data_% table must also contain a column
|
||||
** named "rbu_rowid". This column is mapped to the table's implicit primary
|
||||
** key column - "rowid". Virtual tables for which the "rowid" column does
|
||||
** not function like a primary key value cannot be updated using RBU. For
|
||||
** example, if the target db contains either of the following:
|
||||
**
|
||||
** CREATE VIRTUAL TABLE x1 USING fts3(a, b);
|
||||
@ -136,35 +136,35 @@
|
||||
** CREATE TABLE data_ft1(a, b, langid, rbu_rowid, rbu_control);
|
||||
** CREATE TABLE data_ft1(a, b, rbu_rowid, rbu_control);
|
||||
**
|
||||
** For each row to INSERT into the target database as part of the RBU
|
||||
** For each row to INSERT into the target database as part of the RBU
|
||||
** update, the corresponding data_% table should contain a single record
|
||||
** with the "rbu_control" column set to contain integer value 0. The
|
||||
** other columns should be set to the values that make up the new record
|
||||
** to insert.
|
||||
** other columns should be set to the values that make up the new record
|
||||
** to insert.
|
||||
**
|
||||
** If the target database table has an INTEGER PRIMARY KEY, it is not
|
||||
** possible to insert a NULL value into the IPK column. Attempting to
|
||||
** If the target database table has an INTEGER PRIMARY KEY, it is not
|
||||
** possible to insert a NULL value into the IPK column. Attempting to
|
||||
** do so results in an SQLITE_MISMATCH error.
|
||||
**
|
||||
** For each row to DELETE from the target database as part of the RBU
|
||||
** For each row to DELETE from the target database as part of the RBU
|
||||
** update, the corresponding data_% table should contain a single record
|
||||
** with the "rbu_control" column set to contain integer value 1. The
|
||||
** real primary key values of the row to delete should be stored in the
|
||||
** corresponding columns of the data_% table. The values stored in the
|
||||
** other columns are not used.
|
||||
**
|
||||
** For each row to UPDATE from the target database as part of the RBU
|
||||
** For each row to UPDATE from the target database as part of the RBU
|
||||
** update, the corresponding data_% table should contain a single record
|
||||
** with the "rbu_control" column set to contain a value of type text.
|
||||
** The real primary key values identifying the row to update should be
|
||||
** The real primary key values identifying the row to update should be
|
||||
** stored in the corresponding columns of the data_% table row, as should
|
||||
** the new values of all columns being update. The text value in the
|
||||
** the new values of all columns being update. The text value in the
|
||||
** "rbu_control" column must contain the same number of characters as
|
||||
** there are columns in the target database table, and must consist entirely
|
||||
** of 'x' and '.' characters (or in some special cases 'd' - see below). For
|
||||
** of 'x' and '.' characters (or in some special cases 'd' - see below). For
|
||||
** each column that is being updated, the corresponding character is set to
|
||||
** 'x'. For those that remain as they are, the corresponding character of the
|
||||
** rbu_control value should be set to '.'. For example, given the tables
|
||||
** rbu_control value should be set to '.'. For example, given the tables
|
||||
** above, the update statement:
|
||||
**
|
||||
** UPDATE t1 SET c = 'usa' WHERE a = 4;
|
||||
@ -178,30 +178,30 @@
|
||||
** target table with the value stored in the corresponding data_% column, the
|
||||
** user-defined SQL function "rbu_delta()" is invoked and the result stored in
|
||||
** the target table column. rbu_delta() is invoked with two arguments - the
|
||||
** original value currently stored in the target table column and the
|
||||
** original value currently stored in the target table column and the
|
||||
** value specified in the data_xxx table.
|
||||
**
|
||||
** For example, this row:
|
||||
**
|
||||
** INSERT INTO data_t1(a, b, c, rbu_control) VALUES(4, NULL, 'usa', '..d');
|
||||
**
|
||||
** is similar to an UPDATE statement such as:
|
||||
** is similar to an UPDATE statement such as:
|
||||
**
|
||||
** UPDATE t1 SET c = rbu_delta(c, 'usa') WHERE a = 4;
|
||||
**
|
||||
** Finally, if an 'f' character appears in place of a 'd' or 's' in an
|
||||
** Finally, if an 'f' character appears in place of a 'd' or 's' in an
|
||||
** ota_control string, the contents of the data_xxx table column is assumed
|
||||
** to be a "fossil delta" - a patch to be applied to a blob value in the
|
||||
** format used by the fossil source-code management system. In this case
|
||||
** the existing value within the target database table must be of type BLOB.
|
||||
** the existing value within the target database table must be of type BLOB.
|
||||
** It is replaced by the result of applying the specified fossil delta to
|
||||
** itself.
|
||||
**
|
||||
** If the target database table is a virtual table or a table with no PRIMARY
|
||||
** KEY, the rbu_control value should not include a character corresponding
|
||||
** KEY, the rbu_control value should not include a character corresponding
|
||||
** to the rbu_rowid value. For example, this:
|
||||
**
|
||||
** INSERT INTO data_ft1(a, b, rbu_rowid, rbu_control)
|
||||
** INSERT INTO data_ft1(a, b, rbu_rowid, rbu_control)
|
||||
** VALUES(NULL, 'usa', 12, '.x');
|
||||
**
|
||||
** causes a result similar to:
|
||||
|
@ -190,7 +190,7 @@ const installOpfsVfs = function callee(options){
|
||||
s = metrics.s11n.deserialize = Object.create(null);
|
||||
s.count = s.time = 0;
|
||||
}
|
||||
}/*metrics*/;
|
||||
}/*metrics*/;
|
||||
const opfsVfs = new sqlite3_vfs();
|
||||
const opfsIoMethods = new sqlite3_io_methods();
|
||||
const promiseReject = function(err){
|
||||
@ -743,7 +743,7 @@ const installOpfsVfs = function callee(options){
|
||||
let rc;
|
||||
try {
|
||||
rc = opRun('xRead',pFile, n, Number(offset64));
|
||||
if(0===rc || capi.SQLITE_IOERR_SHORT_READ===rc){
|
||||
if(0===rc || capi.SQLITE_IOERR_SHORT_READ===rc){
|
||||
/**
|
||||
Results get written to the SharedArrayBuffer f.sabView.
|
||||
Because the heap is _not_ a SharedArrayBuffer, we have
|
||||
@ -1291,7 +1291,7 @@ const installOpfsVfs = function callee(options){
|
||||
}).catch(promiseReject);
|
||||
}else{
|
||||
promiseResolve(sqlite3);
|
||||
}
|
||||
}
|
||||
}catch(e){
|
||||
error(e);
|
||||
promiseReject(e);
|
||||
|
16
manifest
16
manifest
@ -1,5 +1,5 @@
|
||||
C Have\ssome\sRBU\stests\srun\sas\spart\sof\sveryquick.test/testrunner.tcl.
|
||||
D 2023-01-26T18:16:51.177
|
||||
C End-of-line\swhitespace\scleanups\sand\sdoc\stypo\sfixes.\sNo\scode\schanges.
|
||||
D 2023-01-26T20:08:59.766
|
||||
F .fossil-settings/empty-dirs dbb81e8fc0401ac46a1491ab34a7f2c7c0452f2f06b54ebb845d024ca8283ef1
|
||||
F .fossil-settings/ignore-glob 35175cdfcf539b2318cb04a9901442804be81cd677d8b889fcc9149c21f239ea
|
||||
F LICENSE.md df5091916dbb40e6e9686186587125e1b2ff51f022cc334e886c19a0e9982724
|
||||
@ -362,7 +362,7 @@ F ext/rbu/rbuvacuum2.test 2643b58f4d8d3573db0f93faae18805a35ab162b4c55ff6b656062
|
||||
F ext/rbu/rbuvacuum3.test 8addd82e4b83b4c93fa47428eae4fd0dbf410f8512c186f38e348feb49ba03dc
|
||||
F ext/rbu/rbuvacuum4.test a78898e438a44803eb2bc897ba3323373c9f277418e2d6d76e90f2f1dbccfd10
|
||||
F ext/rbu/sqlite3rbu.c 348bb6251e6ec459de102f8b2dd50789a98643ef7a28e56e4c787ac9659c15ea
|
||||
F ext/rbu/sqlite3rbu.h 02d981e2d39c151391759e1a400e29c7388730812957ac3db8dad7f6c9f9cfc8
|
||||
F ext/rbu/sqlite3rbu.h 9d923eb135c5d04aa6afd7c39ca47b0d1d0707c100e02f19fdde6a494e414304
|
||||
F ext/rbu/test_rbu.c ee6ede75147bc081fe9bc3931e6b206277418d14d3fbceea6fdc6216d9b47055
|
||||
F ext/recover/dbdata.c dc25628e405c86936c597e28f3e6f56a257029c3034c5ef7f6b10f7c02f41018
|
||||
F ext/recover/recover1.test 2a2df2943d6696f9487e75868feae4b1511c4a511b102854ba0d2af0326d9dfb
|
||||
@ -485,7 +485,7 @@ F ext/wasm/api/sqlite3-api-worker1.js c9ef8865f072e61251260b218aa4ed614a21a25e9e
|
||||
F ext/wasm/api/sqlite3-license-version-header.js a661182fc93fc2cf212dfd0b987f8e138a3ac98f850b1112e29b5fbdaecc87c3
|
||||
F ext/wasm/api/sqlite3-opfs-async-proxy.js 7795b84b66a7a8dedc791340709b310bb497c3c72a80bef364fa2a58e2ddae3f
|
||||
F ext/wasm/api/sqlite3-v-helper.js 6f6c3e390a72e08b0a5b16a0d567d7af3c04d172831853a29d72a6f1dd40ff24
|
||||
F ext/wasm/api/sqlite3-vfs-opfs.c-pp.js 66daf6fb6843bea615fe193109e1542efbeca24f560ee9da63375a910bb48115
|
||||
F ext/wasm/api/sqlite3-vfs-opfs.c-pp.js 50e4f6103dc65556e3e040f9e80eb8f14bfc6f979fa018952859f7755e201b27
|
||||
F ext/wasm/api/sqlite3-wasi.h 25356084cfe0d40458a902afb465df8c21fc4152c1d0a59b563a3fba59a068f9
|
||||
F ext/wasm/api/sqlite3-wasm.c 76625a70937a8522d014ef686c32db5b53a3ee61850323f5c601d2ac39fe52fe
|
||||
F ext/wasm/api/sqlite3-worker1-promiser.js 0c7a9826dbf82a5ed4e4f7bf7816e825a52aff253afbf3350431f5773faf0e4b
|
||||
@ -2044,8 +2044,8 @@ F vsixtest/vsixtest.tcl 6a9a6ab600c25a91a7acc6293828957a386a8a93
|
||||
F vsixtest/vsixtest.vcxproj.data 2ed517e100c66dc455b492e1a33350c1b20fbcdc
|
||||
F vsixtest/vsixtest.vcxproj.filters 37e51ffedcdb064aad6ff33b6148725226cd608e
|
||||
F vsixtest/vsixtest_TemporaryKey.pfx e5b1b036facdb453873e7084e1cae9102ccc67a0
|
||||
P b25eec1c13f6a8c7ba993e5a55e26798f3b67a8b9571998459671cb570cbdfb4
|
||||
R 537c30dd8a98aff8c6e461779736e2c5
|
||||
U dan
|
||||
Z 2c6f919b8fdbc63c1afea9a34b0a629c
|
||||
P f51406e3bf92f2b46f13d08fb7c7fe7683feba68b5a8fa18f6f6b8845662deac
|
||||
R c978e0ce582e6e1cfdd4ca23d28f0447
|
||||
U stephan
|
||||
Z 71857224353d5c38a14866ad03e5be27
|
||||
# Remove this line to create a well-formed Fossil manifest.
|
||||
|
@ -1 +1 @@
|
||||
f51406e3bf92f2b46f13d08fb7c7fe7683feba68b5a8fa18f6f6b8845662deac
|
||||
bdfd72a083fadd724030c4c89adae71426e1ddd402c6bc5abf40801ecf3253cf
|
Loading…
Reference in New Issue
Block a user