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: |
0dc508ed1b6be8672c4b025c9d27c6ce |
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
Changes to pages/appfileformat.in.
︙ | ︙ | |||
287 288 289 290 291 292 293 | 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). | | | | | 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 | <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 | | | < | 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, |
︙ | ︙ |