Documentation Source Text

Check-in [0dc508ed1b]
Login

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

Overview
Comment:One more pass, with a few minor corrections, over the application file format document.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 0dc508ed1b6be8672c4b025c9d27c6ce4e2c2230
User & Date: drh 2014-03-15 12:25:31.966
Context
2014-03-17
18:05
Fix a hyperlink to the "application file format" page. (check-in: 06eecd10f7 user: drh tags: trunk)
2014-03-15
12:25
One more pass, with a few minor corrections, over the application file format document. (check-in: 0dc508ed1b user: drh tags: trunk)
2014-03-14
22:27
More edits to the application-file-format document. (check-in: c0ac5630f2 user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/appfileformat.in.
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
and wrapped pile-of-files formats, both of which usually require a
rewrite of the entire document in order to change a single byte.  
Pure pile-of-files formats can also
do incremental updates to some extent, though the granularity of writes is 
usually larger with pile-of-file formats (a single file) than with SQLite
(a single page).

<p>A desktop application built on SQLite can also do continuous update.
In other words, instead of collecting changes in memory and then writing
them to disk only on a File/Save action, changes can be written back to
the disk as they occur.  The avoids loss of work on a system crash or
power failure.  The undo/redo stack can also be kept in the on-disk 
database, meaning that undo/redo can occur across session boundaries.
Maintenance of the undo/redo stack can often be automated using SQL
triggers.

<li><p><b>Easily Extensible.</b>
As an application grows, new features can be added to an







|
|

|







287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
and wrapped pile-of-files formats, both of which usually require a
rewrite of the entire document in order to change a single byte.  
Pure pile-of-files formats can also
do incremental updates to some extent, though the granularity of writes is 
usually larger with pile-of-file formats (a single file) than with SQLite
(a single page).

<p>SQLite also supports continuous update.
Instead of collecting changes in memory and then writing
them to disk only on a File/Save action, changes can be written back to
the disk as they occur.  This avoids loss of work on a system crash or
power failure.  The undo/redo stack can also be kept in the on-disk 
database, meaning that undo/redo can occur across session boundaries.
Maintenance of the undo/redo stack can often be automated using SQL
triggers.

<li><p><b>Easily Extensible.</b>
As an application grows, new features can be added to an
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385

<li><p><b>Multiple Programming Languages.</b>
Though SQLite is itself written in ANSI-C, interfaces exist for
just about every other programming language you can think of:
C++, C#, Objective-C, Java, Tcl, Perl, Python, Ruby, Erlang,
JavaScript, and so forth.  So programmers can develop in whatever
language they are most comfortable with and which best matches
the needs of the application.

<p>An SQLite application file format is a great 
choice in cases where there is a collection or "federation" of
separate programs, often written in different languages and by
different development teams.
This comes up commonly in research or laboratory
environments where one team is responsible for data acquisition
and other teams are responsible for various stages of analysis.
Each team can use whatever hardware, operating system,
programming language and development methodology that they are 
most comfortable with, and as long as all programs use an SQLite 
database with a common schema as their application file format, 
they can all interoperate.


<li><p><b>Better Applications.</b>
If the application file format is an SQLite database, the complete
documentation for that file format consists of the database schema,
with perhaps a few extra words about what each table and column
represents.  The description of a custom file format,







|











|
<







358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377

378
379
380
381
382
383
384

<li><p><b>Multiple Programming Languages.</b>
Though SQLite is itself written in ANSI-C, interfaces exist for
just about every other programming language you can think of:
C++, C#, Objective-C, Java, Tcl, Perl, Python, Ruby, Erlang,
JavaScript, and so forth.  So programmers can develop in whatever
language they are most comfortable with and which best matches
the needs of the project.

<p>An SQLite application file format is a great 
choice in cases where there is a collection or "federation" of
separate programs, often written in different languages and by
different development teams.
This comes up commonly in research or laboratory
environments where one team is responsible for data acquisition
and other teams are responsible for various stages of analysis.
Each team can use whatever hardware, operating system,
programming language and development methodology that they are 
most comfortable with, and as long as all programs use an SQLite 
database with a common schema, they can all interoperate.



<li><p><b>Better Applications.</b>
If the application file format is an SQLite database, the complete
documentation for that file format consists of the database schema,
with perhaps a few extra words about what each table and column
represents.  The description of a custom file format,