| ︙ | | | ︙ | |
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
because Fossil is a distributed NoSQL database. And, Fossil does use
a modern high-level language for its implementation, namely SQL.
<h2>Fossil Is A NoSQL Database</h2>
We begin with the first question: Fossil is not based on a distributed
NoSQL database because Fossil <u><i>is</i></u> a distributed NoSQL database.
Fossil is <u>not</u> based on SQLite.
The current implementation of Fossil uses
SQLite as a local store for the content of the distributed database and as
a cache for meta-information about the distributed database that is precomputed
for quick and easy presentation. But the use of SQLite in this role is an
implementation detail and is not fundamental to the design. Some future
version of Fossil might do away with SQLite and substitute a pile-of-files or
a key/value database in place of SQLite.
(Actually, that is very unlikely
to happen since SQLite works amazingly well in its current role, but the point
is that omitting SQLite from Fossil is a theoretical possibility.)
The underlying database that Fossil implements has nothing to do with
SQLite, or SQL, or even relational database theory. The underlying
database is very simple: it is an unordered collection of "artifacts".
|
|
|
|
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
because Fossil is a distributed NoSQL database. And, Fossil does use
a modern high-level language for its implementation, namely SQL.
<h2>Fossil Is A NoSQL Database</h2>
We begin with the first question: Fossil is not based on a distributed
NoSQL database because Fossil <u><i>is</i></u> a distributed NoSQL database.
Fossil is <u>not</u> based on SQLite.
The current implementation of Fossil uses
SQLite as a local store for the content of the distributed database and as
a cache for meta-information about the distributed database that is precomputed
for quick and easy presentation. But the use of SQLite in this role is an
implementation detail and is not fundamental to the design. Some future
version of Fossil might do away with SQLite and substitute a pile-of-files or
a key/value database in place of SQLite.
(Actually, that is very unlikely
to happen since SQLite works amazingly well in its current role, but the point
is that omitting SQLite from Fossil is a theoretical possibility.)
The underlying database that Fossil implements has nothing to do with
SQLite, or SQL, or even relational database theory. The underlying
database is very simple: it is an unordered collection of "artifacts".
|
| ︙ | | | ︙ | |
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
So really, Fossil works with two separate databases. There is the
bag-of-artifacts database which is non-relational and distributed (like
a NoSQL database) and there is the local relational database. The
bag-of-artifacts database has a fixed format and is what defines a Fossil
repository. Fossil will never modify the file format of the bag-of-artifacts
database in an incompatible way because to do so would be to make something
that is no longer "Fossil". The local relational database, on the other hand,
is a cache that contains information derived from the bag-of-artifacts.
The schema of the local relational database changes from time to time as
the Fossil implementation is enhanced, and the content is recomputed from
the unchanging bag of artifacts. The local relational database is an
implementation detail which currently happens to use SQLite.
Another way to think of the relational tables in a Fossil repository is
as an index for the artifacts. Without the relational tables,
|
|
|
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
So really, Fossil works with two separate databases. There is the
bag-of-artifacts database which is non-relational and distributed (like
a NoSQL database) and there is the local relational database. The
bag-of-artifacts database has a fixed format and is what defines a Fossil
repository. Fossil will never modify the file format of the bag-of-artifacts
database in an incompatible way because to do so would be to make something
that is no longer "Fossil". The local relational database, on the other hand,
is a cache that contains information derived from the bag-of-artifacts.
The schema of the local relational database changes from time to time as
the Fossil implementation is enhanced, and the content is recomputed from
the unchanging bag of artifacts. The local relational database is an
implementation detail which currently happens to use SQLite.
Another way to think of the relational tables in a Fossil repository is
as an index for the artifacts. Without the relational tables,
|
| ︙ | | | ︙ | |
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
And Fossil doesn't use a distributed
NoSQL database because Fossil is a distributed NoSQL database. That answers
the first question.
<h2>SQL Is A High-Level Scripting Language</h2>
The second concern states that Fossil does not use a high-level scripting
language. But that is not true. Fossil uses SQL (as implemented by SQLite)
as its scripting language.
This misunderstanding likely arises because people fail
to appreciate that SQL is a programming language. People are taught that SQL
is a "query language" as if that were somehow different from a
"programming language". But they really are two different flavors of the
same thing. I find that people do better with SQL if they think of
|
|
|
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
And Fossil doesn't use a distributed
NoSQL database because Fossil is a distributed NoSQL database. That answers
the first question.
<h2>SQL Is A High-Level Scripting Language</h2>
The second concern states that Fossil does not use a high-level scripting
language. But that is not true. Fossil uses SQL (as implemented by SQLite)
as its scripting language.
This misunderstanding likely arises because people fail
to appreciate that SQL is a programming language. People are taught that SQL
is a "query language" as if that were somehow different from a
"programming language". But they really are two different flavors of the
same thing. I find that people do better with SQL if they think of
|
| ︙ | | | ︙ | |
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Much of the "heavy lifting" within the Fossil implementation is carried
out using SQL statements. It is true that these SQL statements are glued
together with C code, but it turns out that C works surprisingly well in
that role. Several early prototypes of Fossil were written in a scripting
language (TCL). We normally find that TCL programs are shorter than the
equivalent C code by a factor of 10 or more. But in the case of Fossil,
the use of TCL was actually making the code longer and more difficult to
understand.
And so in the final design, we switched from TCL to C in order to make
the code easier to implement and debug.
Without the advantages of having SQLite built in, the design might well
have followed a different path. Most reports generated by Fossil involve
a complex set of queries against the relational tables of the repository
database. These queries are normally implemented in only a few dozen
lines of SQL code. But if those queries had been implemented procedurally
using a key/value or pile-of-files database, it
may have well been the case that a high-level scripting language such as
Tcl, Python, or Ruby may have worked out better than C.
|
|
|
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Much of the "heavy lifting" within the Fossil implementation is carried
out using SQL statements. It is true that these SQL statements are glued
together with C code, but it turns out that C works surprisingly well in
that role. Several early prototypes of Fossil were written in a scripting
language (TCL). We normally find that TCL programs are shorter than the
equivalent C code by a factor of 10 or more. But in the case of Fossil,
the use of TCL was actually making the code longer and more difficult to
understand.
And so in the final design, we switched from TCL to C in order to make
the code easier to implement and debug.
Without the advantages of having SQLite built in, the design might well
have followed a different path. Most reports generated by Fossil involve
a complex set of queries against the relational tables of the repository
database. These queries are normally implemented in only a few dozen
lines of SQL code. But if those queries had been implemented procedurally
using a key/value or pile-of-files database, it
may have well been the case that a high-level scripting language such as
Tcl, Python, or Ruby may have worked out better than C.
|