Documentation Source Text

Check-in [521876cfa4]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Merge fixes from the 3.20 release branch
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 521876cfa4f9a5a7c210f1e010f29b864949b89df6560f845bb834dc955cbe8b
User & Date: drh 2017-09-29 12:52:58
Context
2017-10-02
03:42
Mention changes to the use of co-routines in the change log. Provide information on co-routines in the query planner overview document. check-in: 7e35a79626 user: drh tags: trunk
2017-09-29
12:52
Merge fixes from the 3.20 release branch check-in: 521876cfa4 user: drh tags: trunk
12:50
Consistent name for the "SQLite In 5 Minutes Or Less" document. Leaf check-in: 14bfb3bcf4 user: drh tags: branch-3.20
2017-09-15
21:15
Minor documentation updates. check-in: 0896528c21 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/atomiccommit.in.

63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
  for flash memory is usually larger than 512 bytes.  For these reasons,
  versions of SQLite beginning with 3.3.14 have a method in the OS
  interface layer that interrogates the underlying filesystem to find
  the true sector size.  As currently implemented (version 3.5.0) this
  method still returns a hard-coded value of 512 bytes, since there
  is no standard way of discovering the true sector size on either
  Unix or Windows.  But the method is available for embedded device
  manufactures to tweak according to their own needs.  And we have
  left open the possibility of filling in a more meaningful implementation
  on Unix and Windows in the future.</p>

<p>SQLite has traditionally assumed that a sector write is <u>not</u> atomic.
However, SQLite does always assume that a sector write is linear.  By "linear"
we mean that SQLite assumes that when writing a sector, the hardware begins
at one end of the data and writes byte by byte until it gets to







|







63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
  for flash memory is usually larger than 512 bytes.  For these reasons,
  versions of SQLite beginning with 3.3.14 have a method in the OS
  interface layer that interrogates the underlying filesystem to find
  the true sector size.  As currently implemented (version 3.5.0) this
  method still returns a hard-coded value of 512 bytes, since there
  is no standard way of discovering the true sector size on either
  Unix or Windows.  But the method is available for embedded device
  manufacturers to tweak according to their own needs.  And we have
  left open the possibility of filling in a more meaningful implementation
  on Unix and Windows in the future.</p>

<p>SQLite has traditionally assumed that a sector write is <u>not</u> atomic.
However, SQLite does always assume that a sector write is linear.  By "linear"
we mean that SQLite assumes that when writing a sector, the hardware begins
at one end of the data and writes byte by byte until it gets to

Changes to pages/capi3ref.in.

230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
<h1 align="center">
C-language Interface Specification for SQLite
</h1>

<p>These pages are intended to be precise and detailed specification.
For a tutorial introduction, see instead:
<ul>
<li>[quickstart | SQLite In 3 Minutes Or Less] and/or
<li>the [cintro | Introduction To The SQLite C/C++ Interface].
</ul>
This same content is also available as a
<a href="../capi3ref.html">single large HTML file</a>.
</p>

<p>The SQLite interface elements can be grouped into three categories:</p>







|







230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
<h1 align="center">
C-language Interface Specification for SQLite
</h1>

<p>These pages are intended to be precise and detailed specification.
For a tutorial introduction, see instead:
<ul>
<li>[quickstart | SQLite In 5 Minutes Or Less] and/or
<li>the [cintro | Introduction To The SQLite C/C++ Interface].
</ul>
This same content is also available as a
<a href="../capi3ref.html">single large HTML file</a>.
</p>

<p>The SQLite interface elements can be grouped into three categories:</p>

Changes to pages/cintro.in.

114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
...
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
  Many of these routines come in multiple versions.
  For example, the list above shows a single routine
  named [sqlite3_open()] when in fact there are three separate routines
  that accomplish the same thing in slightly different ways:
  [sqlite3_open()], [sqlite3_open16()] and [sqlite3_open_v2()].
  The list mentions [sqlite3_column_int | sqlite3_column()]
  when in fact no such routine exists.
  The "sqlite3_column()" shown in the list is place holders for
  an entire family of routines to be used for extracting column
  data in various datatypes.
</p>

<p>
  Here is a summary of what the core interfaces do:
</p>

................................................................................
  during initialization.
  Note that [sqlite3_open()] can be used to either open existing database
  files or to create and open new database files.
  While many applications use only a single [database connection], there is
  no reason why an application cannot call [sqlite3_open()] multiple times
  in order to open multiple [database connections] - either to the same
  database or to different databases.  Sometimes a multi-threaded application
  will create separate [database connections] for each threads.
  Note that a single [database connection] can access two or more
  databases using the [ATTACH] SQL command, so it is not necessary to
  have a separate database connection for each database file.
</p>

<p>
  Many applications destroy their [database connections] using calls to







|
|







 







|







114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
...
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
  Many of these routines come in multiple versions.
  For example, the list above shows a single routine
  named [sqlite3_open()] when in fact there are three separate routines
  that accomplish the same thing in slightly different ways:
  [sqlite3_open()], [sqlite3_open16()] and [sqlite3_open_v2()].
  The list mentions [sqlite3_column_int | sqlite3_column()]
  when in fact no such routine exists.
  The "sqlite3_column()" shown in the list is a placeholder for
  an entire family of routines that extra column
  data in various datatypes.
</p>

<p>
  Here is a summary of what the core interfaces do:
</p>

................................................................................
  during initialization.
  Note that [sqlite3_open()] can be used to either open existing database
  files or to create and open new database files.
  While many applications use only a single [database connection], there is
  no reason why an application cannot call [sqlite3_open()] multiple times
  in order to open multiple [database connections] - either to the same
  database or to different databases.  Sometimes a multi-threaded application
  will create separate [database connections] for each thread.
  Note that a single [database connection] can access two or more
  databases using the [ATTACH] SQL command, so it is not necessary to
  have a separate database connection for each database file.
</p>

<p>
  Many applications destroy their [database connections] using calls to

Changes to pages/fasterthanfs.in.

78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
at which direct file I/O becomes faster is smaller than it is in Gray's
paper.

<p>
The [Internal Versus External BLOBs] article on this website is an
earlier investigation (circa 2011) that uses the same approach as the
Jim Gray paper &mdash; storing the blob filenames as entries in the
database &mdash but for SQLite instead of SQL Server.



<h1>How These Measurements Are Made</h1>

<p>I/O performance is measured using the
[https://www.sqlite.org/src/file/test/kvtest.c|kvtest.c] program







|







78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
at which direct file I/O becomes faster is smaller than it is in Gray's
paper.

<p>
The [Internal Versus External BLOBs] article on this website is an
earlier investigation (circa 2011) that uses the same approach as the
Jim Gray paper &mdash; storing the blob filenames as entries in the
database &mdash; but for SQLite instead of SQL Server.



<h1>How These Measurements Are Made</h1>

<p>I/O performance is measured using the
[https://www.sqlite.org/src/file/test/kvtest.c|kvtest.c] program