Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Clarify that the values stored in the rowid of an FTS3 table do not change when the database is VACUUMed. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
39d5f660c5e177fa8efb9126549eb299 |
| User & Date: | dan 2009-12-04 07:50:34 |
Context
|
2009-12-05
| ||
| 19:07 | Fix a minor typo in fts3.html. (check-in: a92e1357cb user: dan tags: trunk) | |
|
2009-12-04
| ||
| 07:50 | Clarify that the values stored in the rowid of an FTS3 table do not change when the database is VACUUMed. (check-in: 39d5f660c5 user: dan tags: trunk) | |
|
2009-12-03
| ||
| 18:14 | Change 3.6.21 release date. Fix typos reported by internet reviewers. (check-in: c922c8ef50 user: drh tags: trunk) | |
Changes
Changes to pages/fts3.in.
143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 |
<p>
FTS3 tables are populated using \[INSERT\], \[UPDATE\] and \[DELETE\]
statements in the same way as ordinary SQLite tables are.
<p>
As well as the columns named by the user (or the "content" column if no
module arguments where specified as part of the \[CREATE VIRTUAL TABLE\]
statement), each FTS3 table has a "rowid" column that behaves like an
\[INTEGER PRIMARY KEY\], except that values remain unchanged if the
database is rebuilt using the \[VACUUM\] command. For FTS3 tables, "docid"
is allowed as an alias along with the usual "rowid", "oid" and "_oid_"
identifiers. Attempting to insert or update a row with a docid value that
already exists in the table is an error, just as it would be with an
ordinary SQLite table.
<p>
There is one other subtle difference between "docid" and the normal SQLite
aliases for the rowid column. Normally, if an INSERT or UPDATE statement
assigns discreet values to two or more aliases of the rowid column, SQLite
writes the rightmost of such values specified in the INSERT or UPDATE
statement to the database. However, assigning a non-NULL value to both
|
| | > | | | | | |
143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 |
<p>
FTS3 tables are populated using \[INSERT\], \[UPDATE\] and \[DELETE\]
statements in the same way as ordinary SQLite tables are.
<p>
As well as the columns named by the user (or the "content" column if no
module arguments where specified as part of the \[CREATE VIRTUAL TABLE\]
statement), each FTS3 table has a "rowid" column. The rowid of an FTS3
table behaves in the same way as the rowid column of an ordinary SQLite
table, except that the values stored in the rowid column of an FTS3 table
remain unchanged if the database is rebuilt using the \[VACUUM\] command.
For FTS3 tables, "docid" is allowed as an alias along with the usual "rowid",
"oid" and "_oid_" identifiers. Attempting to insert or update a row with a
docid value that already exists in the table is an error, just as it would
be with an ordinary SQLite table.
<p>
There is one other subtle difference between "docid" and the normal SQLite
aliases for the rowid column. Normally, if an INSERT or UPDATE statement
assigns discreet values to two or more aliases of the rowid column, SQLite
writes the rightmost of such values specified in the INSERT or UPDATE
statement to the database. However, assigning a non-NULL value to both
|