/ Check-in [fee0c5e3]
Login
SQLite training in Houston TX on 2019-11-05 (details)
Part of the 2019 Tcl Conference

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

Overview
Comment:Fix typos in documentation. Fix publish.sh so that it correctly builds the ZIP archive of preprocesses source code. (CVS 1620)
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: fee0c5e308c3de1937185e2060c8757e605ab3a2
User & Date: drh 2004-06-18 15:13:48
Context
2004-06-18
17:10
Changes to allow libsqlite3.a and libsqlite.a to be both linked into the same program at the same time. (CVS 1621) check-in: 2590fffc user: drh tags: trunk
15:13
Fix typos in documentation. Fix publish.sh so that it correctly builds the ZIP archive of preprocesses source code. (CVS 1620) check-in: fee0c5e3 user: drh tags: trunk
12:29
Version 3.0.0 (ALPHA) (CVS 1619) check-in: 8b409aaa user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to publish.sh.

30
31
32
33
34
35
36
37
38
39

40
41
42
43
44
45
46
gzip sqlite3-$VERS.bin
mv sqlite3-$VERS.bin.gz doc

# Build the tclsqlite.so shared library for import into tclsh or wish
# under Linux
#
make target_source
rm sqlite_source.zip
cd tsrc
zip ../sqlite_source.zip *

rm shell.c
TCLDIR=/home/drh/tcltk/8.2linux
TCLSTUBLIB=$TCLDIR/libtclstub8.2g.a
OPTS='-DUSE_TCL_STUBS=1 -DNDEBUG=1'
gcc -fPIC $OPTS -O2 -I. -I$TCLDIR -shared *.c $TCLSTUBLIB -o tclsqlite.so
strip tclsqlite.so
mv tclsqlite.so tclsqlite-$VERS.so







<

<
>







30
31
32
33
34
35
36

37

38
39
40
41
42
43
44
45
gzip sqlite3-$VERS.bin
mv sqlite3-$VERS.bin.gz doc

# Build the tclsqlite.so shared library for import into tclsh or wish
# under Linux
#
make target_source

cd tsrc

zip ../doc/sqlite-source-$VERSW.zip *
rm shell.c
TCLDIR=/home/drh/tcltk/8.2linux
TCLSTUBLIB=$TCLDIR/libtclstub8.2g.a
OPTS='-DUSE_TCL_STUBS=1 -DNDEBUG=1'
gcc -fPIC $OPTS -O2 -I. -I$TCLDIR -shared *.c $TCLSTUBLIB -o tclsqlite.so
strip tclsqlite.so
mv tclsqlite.so tclsqlite-$VERS.so

Changes to www/version3.tcl.

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
..
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
...
278
279
280
281
282
283
284
285
</p>

<h3>New File Format</h3>

<p>
The format used by SQLite database files has been completely revised.
The old version 2.1 format and the new 3.0 format are incompatible with
one another.  Version 2.8 of SQLite will not read and version 3.0 database
files and version 3.0 of SQLite will not read a version 2.8 database file.
</p>

<p>
To convert an SQLite 2.8 database into an SQLite 3.0 database, have
ready the command-line shells for both version 2.8 and 3.0.  Then
enter a command like the following:
................................................................................
</p>

<blockquote><pre>
sqlite OLD.DB .dump | sqlite3 NEW.DB
</pre></blockquote>

<p>
The new database file format uses B+Trees for tables.  In a B+Tree, all
data is stored in the leaves of the tree instead of in both the leaves and
the intermediate branch nodes.  The use of B+Trees for tables allows for
better scalability and the storage larger data fields without the use of
overflow pages.  Traditional B-Trees are still used for indices.</p>

<p>
The new file format also supports variable pages sizes between 512 and
65536 bytes.  The size of a page is stored in the file header so the
same library can read databases with different pages sizes, in theory,
though this feature has not yet been implemented in practice.
</p>

<p>
The new file format omits unused fields from its disk images.  For example,
indices use only the key part of a B-Tree record and not the data.  So
for indices, the field that records the length of the data is omitted.
Integer values such as the length of key and data are stored using
a variable-length encoding so that only one or two bytes are required to
store the most common cases but up to 64-bits of information can be encoded
if needed. 
Integer and floating point data is stored on the disk in binary rather
than being converted into ASCII as in SQLite version 2.8.
These changes taken together result in database files that are typically
25% to 35% smaller than the equivalent files in SQLite version 2.8.
</p>

<p>
Details of the low-level B-Tree format used in SQLite version 3.0 can
be found in header comments to the 
<a href="http://www.sqlite.org/cvstrac/getfile/sqlite/src/btree.c">btree.c</a>
source file.
</p>

<h3>Manifest Typing and BLOB Support</h3>

................................................................................
to mean two or more database files, then it is entirely possible for
two processes to be writing to the same database at the same time.
To further support this capability, commits of transactions involving
two or more ATTACHed database are now atomic.
</p>

}
footer {$Id: version3.tcl,v 1.1 2004/06/17 19:04:17 drh Exp $}







|







 







|

|
|
|










|












|







 







|
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
..
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
...
278
279
280
281
282
283
284
285
</p>

<h3>New File Format</h3>

<p>
The format used by SQLite database files has been completely revised.
The old version 2.1 format and the new 3.0 format are incompatible with
one another.  Version 2.8 of SQLite will not read a version 3.0 database
files and version 3.0 of SQLite will not read a version 2.8 database file.
</p>

<p>
To convert an SQLite 2.8 database into an SQLite 3.0 database, have
ready the command-line shells for both version 2.8 and 3.0.  Then
enter a command like the following:
................................................................................
</p>

<blockquote><pre>
sqlite OLD.DB .dump | sqlite3 NEW.DB
</pre></blockquote>

<p>
The new database file format uses B+trees for tables.  In a B+tree, all
data is stored in the leaves of the tree instead of in both the leaves and
the intermediate branch nodes.  The use of B+trees for tables allows for
better scalability and the storage of larger data fields without the use of
overflow pages.  Traditional B-trees are still used for indices.</p>

<p>
The new file format also supports variable pages sizes between 512 and
65536 bytes.  The size of a page is stored in the file header so the
same library can read databases with different pages sizes, in theory,
though this feature has not yet been implemented in practice.
</p>

<p>
The new file format omits unused fields from its disk images.  For example,
indices use only the key part of a B-tree record and not the data.  So
for indices, the field that records the length of the data is omitted.
Integer values such as the length of key and data are stored using
a variable-length encoding so that only one or two bytes are required to
store the most common cases but up to 64-bits of information can be encoded
if needed. 
Integer and floating point data is stored on the disk in binary rather
than being converted into ASCII as in SQLite version 2.8.
These changes taken together result in database files that are typically
25% to 35% smaller than the equivalent files in SQLite version 2.8.
</p>

<p>
Details of the low-level B-tree format used in SQLite version 3.0 can
be found in header comments to the 
<a href="http://www.sqlite.org/cvstrac/getfile/sqlite/src/btree.c">btree.c</a>
source file.
</p>

<h3>Manifest Typing and BLOB Support</h3>

................................................................................
to mean two or more database files, then it is entirely possible for
two processes to be writing to the same database at the same time.
To further support this capability, commits of transactions involving
two or more ATTACHed database are now atomic.
</p>

}
footer {$Id: version3.tcl,v 1.2 2004/06/18 15:13:48 drh Exp $}