Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Typo fixes from Johannes Laire on unreleased documents. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
e3943543c8022c8a4a65dc790c804046 |
User & Date: | drh 2016-04-04 12:24:03.982 |
Context
2016-04-04
| ||
12:24 | Merge typo fixes from the 3.12.0 branch. (check-in: 8370e949b7 user: drh tags: trunk) | |
12:24 | Typo fixes from Johannes Laire on unreleased documents. (check-in: e3943543c8 user: drh tags: trunk) | |
2016-04-01
| ||
16:08 | Create a place-holder for a tutorial on the session extension. (check-in: 24e5940ece user: drh tags: trunk) | |
Changes
Changes to pages/rowidtable.in.
︙ | ︙ | |||
47 48 49 50 51 52 53 | special names, then those names refer to the declared columns, not to the underlying [rowid]. <li><p> Access to records via [rowid] is highly optimized and very fast. <li><p> | | | 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 | special names, then those names refer to the declared columns, not to the underlying [rowid]. <li><p> Access to records via [rowid] is highly optimized and very fast. <li><p> If the [rowid] is not aliased by [INTEGER PRIMARY KEY] then it is not persistent and might change. In particular the [VACUUM] command will change rowids for tables that do not declare an INTEGER PRIMARY KEY. Therefore, applications should not normally access the rowid directly, but instead use an INTEGER PRIMARY KEY. <li><p> In the underlying [file format], each rowid is stored as a |
︙ | ︙ |
Changes to pages/sessionintro.in.
︙ | ︙ | |||
27 28 29 30 31 32 33 | changes together into a single unified design. <p>The session extension facilitates this by recording all changes to both Alice's and Bob's databases and writing those changes into changeset or patchset files. At the end of the day, Alice can send her changeset to Bob and Bob can "apply" it to his database. The result (assuming there are no conflicts) is that Bob's database then contains both his | | | | 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | changes together into a single unified design. <p>The session extension facilitates this by recording all changes to both Alice's and Bob's databases and writing those changes into changeset or patchset files. At the end of the day, Alice can send her changeset to Bob and Bob can "apply" it to his database. The result (assuming there are no conflicts) is that Bob's database then contains both his changes and Alice's changes. Likewise, Bob can send a changeset of his work over to Alice and she can apply his changes to her database. <p>In other words, the session extension provides a facility for SQLite database files that is similar to the unix [https://en.wikipedia.org/wiki/Patch_(Unix)|patch] utility program, or to the "merge" capabilities of version control systems such as [https://www.fossil-scm.org/|Fossil], [https://git-scm.com|Git], or [http://www.mercurial-scm.org/|Mercurial]. <h3>1.2 Requirements And Limitations</h3> <ul> <li><p> The session extension requires the [SQLITE_ENABLE_PREUPDATE_HOOK] |
︙ | ︙ |