Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Updates to the architecture document. (CVS 1294) |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
c661cc81b6981c536c107f40525ad978 |
| User & Date: | drh 2004-03-14 11:57:58 |
Context
|
2004-03-14
| ||
| 22:12 | Make sqlite_encode_binary() and sqlite_decode_binary() an official part of the library. (CVS 1295) (check-in: 786fe545 user: drh tags: trunk) | |
| 11:57 | Updates to the architecture document. (CVS 1294) (check-in: c661cc81 user: drh tags: trunk) | |
|
2004-03-13
| ||
| 14:00 | Fix the min/max optimizer so that it works when the FROM clause is a subquery. Ticket #658. (CVS 1293) (check-in: 31c94acc user: drh tags: trunk) | |
Changes
Changes to www/arch.tcl.
1 2 3 4 5 6 7 8 9 10 11 .. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 ... 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 ... 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 |
#
# Run this Tcl script to generate the sqlite.html file.
#
set rcsid {$Id: arch.tcl,v 1.10 2004/02/18 16:56:32 drh Exp $}
puts {<html>
<head>
<title>Architecture of SQLite</title>
</head>
<body bgcolor=white>
<h1 align=center>
................................................................................
<p>
There are two main C interfaces to the SQLite library:
<b>sqlite_exec()</b> and <b>sqlite_compile()</b>. Prior to
version 2.8.0 (2003-Feb-16) only sqlite_exec() was supported.
For version 2.8.0, the sqlite_exec and sqlite_compile methods
existed as peers. Beginning with version 2.8.13, the sqlite_compile
method is the primary interface, and sqlite_exec is implemented
using sqlite_compile. Externally, there are API extensions but
not changes that break backwards compatibility. But internally,
the plumbing is very different. The diagram at the right shows
the structure of SQLite for version 2.8.13 and following.
</p>
<h2>Interface</h2>
<p>Much of the public interface to the SQLite library is implemented by
................................................................................
lemon is found in the "doc" subdirectory of the distribution.
</p>
<h2>Code Generator</h2>
<p>After the parser assembles tokens into complete SQL statements,
it calls the code generator to produce virtual machine code that
will do the work that the SQL statements request. There are seven
files in the code generator: <b>build.c</b>, <b>delete.c</b>,
<b>expr.c</b>, <b>insert.c</b> <b>select.c</b>, <b>update.c</b>,
and <b>where.c</b>.
In these files is where most of the serious magic happens.
<b>expr.c</b> handles code generation for expressions.
<b>where.c</b> handles code generation for WHERE clauses on
SELECT, UPDATE and DELETE statements. The files
<b>delete.c</b>, <b>insert.c</b>, <b>select.c</b>, and
<b>update.c</b> handle the code generation for SQL statements
with the same names. (Each of these files calls routines
in <b>expr.c</b> and <b>where.c</b> as necessary.) All other
SQL statements are coded out of <b>build.c</b>.</p>
<h2>Virtual Machine</h2>
<p>The program generated by the code generator is executed by
the virtual machine. Additional information about the virtual
................................................................................
machine is <a href="opcode.html">available separately</a>.
To summarize, the virtual machine implements an abstract computing
engine specifically designed to manipulate database files. The
machine has a stack which is used for intermediate storage.
Each instruction contains an opcode and
up to three additional operands.</p>
<p>The virtual machine is entirely contained in a single
source file <b>vdbe.c</b>. The virtual machine also has
its own header file <b>vdbe.h</b> that defines an interface
between the virtual machine and the rest of the SQLite library.</p>
<h2>Backend</h2>
<p>The backend is an abstraction layer that presents a uniform interface
to the virtual machine for either the B-Tree drivers for disk-based
databases or the Red/Black Tree driver for in-memory databases.
The <b>btree.h</b> source file contains the details.</p>
|
| | | | | > | > | | | | | | | > > > > |
1 2 3 4 5 6 7 8 9 10 11 .. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 ... 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 ... 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 |
#
# Run this Tcl script to generate the sqlite.html file.
#
set rcsid {$Id: arch.tcl,v 1.11 2004/03/14 11:57:58 drh Exp $}
puts {<html>
<head>
<title>Architecture of SQLite</title>
</head>
<body bgcolor=white>
<h1 align=center>
................................................................................
<p>
There are two main C interfaces to the SQLite library:
<b>sqlite_exec()</b> and <b>sqlite_compile()</b>. Prior to
version 2.8.0 (2003-Feb-16) only sqlite_exec() was supported.
For version 2.8.0, the sqlite_exec and sqlite_compile methods
existed as peers. Beginning with version 2.8.13, the sqlite_compile
method is the primary interface, and sqlite_exec is implemented
using sqlite_compile. Externally, this change is an enhancement
that maintains backwards compatibility. But internally,
the plumbing is very different. The diagram at the right shows
the structure of SQLite for version 2.8.13 and following.
</p>
<h2>Interface</h2>
<p>Much of the public interface to the SQLite library is implemented by
................................................................................
lemon is found in the "doc" subdirectory of the distribution.
</p>
<h2>Code Generator</h2>
<p>After the parser assembles tokens into complete SQL statements,
it calls the code generator to produce virtual machine code that
will do the work that the SQL statements request. There are many
files in the code generator: <b>build.c</b>, <b>copy.c</b>,
<b>delete.c</b>,
<b>expr.c</b>, <b>insert.c</b>, <b>pragma.c</b>,
<b>select.c</b>, <b>trigger.c</b>, <b>update.c</b>, <b>vacuum.c</b>
and <b>where.c</b>.
In these files is where most of the serious magic happens.
<b>expr.c</b> handles code generation for expressions.
<b>where.c</b> handles code generation for WHERE clauses on
SELECT, UPDATE and DELETE statements. The files <b>copy.c</b>,
<b>delete.c</b>, <b>insert.c</b>, <b>select.c</b>, <b>trigger.c</b>
<b>update.c</b>, and <b>vacuum.c</b> handle the code generation
for SQL statements with the same names. (Each of these files calls routines
in <b>expr.c</b> and <b>where.c</b> as necessary.) All other
SQL statements are coded out of <b>build.c</b>.</p>
<h2>Virtual Machine</h2>
<p>The program generated by the code generator is executed by
the virtual machine. Additional information about the virtual
................................................................................
machine is <a href="opcode.html">available separately</a>.
To summarize, the virtual machine implements an abstract computing
engine specifically designed to manipulate database files. The
machine has a stack which is used for intermediate storage.
Each instruction contains an opcode and
up to three additional operands.</p>
<p>The virtual machine itself is entirely contained in a single
source file <b>vdbe.c</b>. The virtual machine also has
its own header files: <b>vdbe.h</b> that defines an interface
between the virtual machine and the rest of the SQLite library and
<b>vdbeInt.h</b> which defines structure private the virtual machine.
The <b>vdbeaux.c</b> file contains utilities used by the virtual
machine and interface modules used by the rest of the library to
construct VM programs.</p>
<h2>Backend</h2>
<p>The backend is an abstraction layer that presents a uniform interface
to the virtual machine for either the B-Tree drivers for disk-based
databases or the Red/Black Tree driver for in-memory databases.
The <b>btree.h</b> source file contains the details.</p>
|