Documentation Source Text

Check-in [1e78d197a1]
Login

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

Overview
Comment:Updates to the "serverless" page to talk about resent definitions of that word. Add a skeleton for the "quirks" document.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 1e78d197a168f990bd17985348a51143975348afcb9417cc2d354bb3f068c068
User & Date: drh 2018-04-02 15:25:54
Context
2018-04-03
12:02
Work on the "quirks.html" page. The page is still incomplete, but I need to divert attention to other issues so I'm checking in partial changes. check-in: 508297d763 user: drh tags: trunk
2018-04-02
15:25
Updates to the "serverless" page to talk about resent definitions of that word. Add a skeleton for the "quirks" document. check-in: 1e78d197a1 user: drh tags: trunk
11:10
Version 3.23.0 check-in: 9f377d4453 user: drh tags: trunk, release, version-3.23.0
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/different.in.

30
31
32
33
34
35
36



37
38
39
40
41
42
43
  <p>
  Other more familiar database engines run great once you get them going.
  But doing the initial installation and configuration can be
  intimidatingly complex.
}

feature serverless {Serverless} {



  Most SQL database engines are implemented as a separate server
  process.  Programs that want to access the database communicate
  with the server using some kind of interprocess communication
  (typically TCP/IP) to send requests to the server and to receive
  back results.  SQLite does not work this way.  With SQLite, the
  process that wants to access the database reads and writes
  directly from the database files on disk.  There is no intermediary







>
>
>







30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
  <p>
  Other more familiar database engines run great once you get them going.
  But doing the initial installation and configuration can be
  intimidatingly complex.
}

feature serverless {Serverless} {
  <p>
  <i>(See also the [serverless] documentation page.)</i>
  <p>
  Most SQL database engines are implemented as a separate server
  process.  Programs that want to access the database communicate
  with the server using some kind of interprocess communication
  (typically TCP/IP) to send requests to the server and to receive
  back results.  SQLite does not work this way.  With SQLite, the
  process that wants to access the database reads and writes
  directly from the database files on disk.  There is no intermediary

Added pages/quirks.in.

















































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
<title>Quirks, Caveats, and Gotchas In SQLite</title>
<tcl>hd_keywords {Quirks}</tcl>

<table_of_contents>

<h1>Overview</h1>

<center><font color="red" size=6><b>
This document is a work in progress.
</b></font>
</center>

<p>
The SQL language is a "standard".
Even so, no two SQL database engines work exactly alike.
Every SQL implementation has it own peculiarities and oddities,
and SQLite is no exception to this rule.

<p>
This document strives to highlight the principal differences
between SQLite and other SQL implementations, as an aid to developers
that are porting to or from SQLite or who are trying to build a
system that works across multiple database engines.

<h1>SQLite Is Embedded, Not Client-Server</h1>

<h1>Flexible Typing</h1>

<h1>Foreign Key Enforcement Is Off By Default</h1>

<h1>PRIMARY KEYs Can Sometimes Contain NULLs</h1>

<h1>Aggregate Queries Can Contain Non-Aggregate Result Columns
That Are Not In The GROUP BY Clause</h1>

<h1>Double-quoted String Literals Are Accepted</h1>

<h1>AUTOINCREMENT Does Not Work The Same As MySQL</h1>

<h1>Keywords Can Often Be Used As Identifiers</h1>

Changes to pages/serverless.in.

1
2
3


4
5
6
7
8
9
10
11
..
37
38
39
40
41
42
43






















































<title>SQLite Is Serverless</title>
<tcl>hd_keywords {serverless} {embedded}</tcl>



<h2>SQLite Is Serverless</h2>

<p>
Most SQL database engines are implemented as a separate server process.
Programs that want to access the database communicate with the server
using some kind of interprocess communication (typically TCP/IP) to send 
requests to the server and to receive back results. 
SQLite does not work this way. 
................................................................................

<p>
Most SQL database engines are client/server based. 
Of those that are serverless, SQLite is the only one
known to this author that allows multiple applications
to access the same database at the same time. 
</p>

























































>
>
|







 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
..
39
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
98
99
<title>SQLite Is Serverless</title>
<tcl>hd_keywords {serverless} {embedded}</tcl>

<fancy_format>

<h1>SQLite Is Serverless</h1>

<p>
Most SQL database engines are implemented as a separate server process.
Programs that want to access the database communicate with the server
using some kind of interprocess communication (typically TCP/IP) to send 
requests to the server and to receive back results. 
SQLite does not work this way. 
................................................................................

<p>
Most SQL database engines are client/server based. 
Of those that are serverless, SQLite is the only one
known to this author that allows multiple applications
to access the same database at the same time. 
</p>

<h1>Classic Serverless Vs. Neo-Serverless</h1>

<p>
<i>(This section was added on 2018-04-02)</i>

<p>
Recently, folks have begun to use the
word "serverless" to mean something subtly different from its intended
meaning in this document.  Here are two possible definitions of "serverless":

<ol>
<li><p>
<b>Classic Serverless:</b>
The database engine runs within the same process, thread, and address space
as the application.  There is no message passing or network activity.

<li><p>
<b>Neo-Serverless:</b>
The database engine runs in a separate namespace from the application,
probably on a separate machine, but the database is provided as a
turn-key service by the hosting provider, requires no management or
administration by the application owners, and is so easy to use
that the developers can think of the database as being serverless
even if it really does use a server under the covers.
</ol>

<p>
SQLite is an example of a classic serverless database engine.
With SQLite, there are no other processes, threads, machines, or
other mechanisms (apart from host computer OS and filesystem)
to help provide database services or implementation.  There really
is no server.

<p>
[https://docs.microsoft.com/en-us/azure/cosmos-db/serverless-computing-database|Microsoft Azure Cosmo DB]
and
[https://aws.amazon.com/s3/|Amazon S3]
are examples of a neo-serverless databases.
These database are implemented by server processes running separately
in the cloud.
But the servers are maintained and administered by the ISP, not by
the application developer.
Application developers just use the service.  Developers do not have to
provision, configure, or manage database server instances, as all of that
work is handled automatically by the service provider.  Database servers
do in fact exist, they are just hidden from the developers.

<p>
It is important to understand these two different definitions for
"serverless".
When a database claims to be "serverless",
be sure to discern whether they mean "classic serverless"
or "neo-serverless".