Documentation Source Text

<tcl>hd_keywords {What If OpenOffice Used SQLite} \
{OpenOffice case study}</tcl>
<title>What If OpenDocument Used SQLite?</title>

<h1 align="center">
What If OpenDocument Used SQLite?</h1>

<h2>Introduction</h2>

<p>Suppose the
[http://en.wikipedia.org/wiki/OpenDocument|OpenDocument] file format,
and specifically the "ODP" OpenDocument Presentation format, were
built around SQLite.  Benefits would include:
<ul>
<li>Smaller documents
<li>Faster File/Save times
<li>Faster startup times
<li>Less memory used
<li>Document versioning

and constraints to enforce consistency of content even in the face of
programming errors.  Further enhancement ideas include:
<ul>
<li> Store an [automated undo/redo stack] in a database table so that
     Undo could go back into prior edit sessions.
<li> Add [FTS4|full text search] capabilities to the slide deck, or across
     multiple slide decks.
<li> Decompose the "settings.xml" file into an SQL table that
     is more easily viewed and edited by separate applications.
<li> Break out the "Presentor Notes" from each slide into a separate
     table, for easier access from third-party applications and/or scripts.
<li> Enhance the presentation concept beyond the simple linear sequence of
     slides to allow for side-tracks and excursions to be taken depending on
     how the audience is responding.
</ul>

If protections are disabled, database corruption may occur.

<p>The following are examples of disabling the built-in protection
mechanisms of SQLite:

<ul>
<li><p>Setting [PRAGMA synchronous=OFF] can cause the database to
go corrupt if there is an operating-system crash or power failure,
though this setting is safe from damage due to application crashes.

<li><p>Changing the [PRAGMA schema_version] while other database
connections are open.

<li><p>Using [PRAGMA journal_mode=OFF] or [PRAGMA journal_mode=MEMORY]
and taking an application crash in the middle of a write transaction.

<p>A different temporary file is created each time, so that just like as
with the special ":memory:" string, two database connections to temporary
databases each have their own private database.  Temporary databases are
automatically deleted when the connection that created them closes.</p>

<p>Even though a disk file is allocated for each temporary database, in
practice the temporary database usually resides in the in-memory pager
cache and hence there is very little difference between a pure in-memory
database
created by ":memory:" and a temporary database created by an empty filename.
The only difference is that a ":memory:" database must remain in memory
at all times whereas parts of a temporary database might be flushed to
disk if database becomes large or if SQLite comes under memory pressure.</p>

<p>The previous paragraphs describe the behavior of temporary databases
under the default SQLite configuration.  An application can use the
[temp_store pragma] and the [SQLITE_TEMP_STORE] compile-time parameter to
force temporary databases to behave as pure in-memory databases, if desired.

  incr tabcnt
  hd_puts "<li value='$tabcnt'>\n"
  set fx [string trim $fx]
  set hlink "<a href='#$lnk'>"
  regsub -all {^json\(} $fx "${hlink}json</a>(" fx
  regsub -all {(json_[a-z_]+)} $fx "$hlink\\1</a>" fx
  regsub -all {(value[1-9]?|path|label[1-9]?)} $fx "<i>\\1</i>" fx
  regsub -all {(json[1-9]?|name)} $fx "<i>\\1</i>" fx
  hd_puts "$fx\n"
  # hd_puts "[string trim $desc]\n"
  hd_puts "</li>\n\n"
}
set tsctr 100

tabentry {json(json)} {

a suite of test cases for SQLite that provide 100% branch test coverage
(and 100% modified condition/decision coverage) for the core SQLite in
an as-deployed configuration using only published and documented interfaces.
TH3 is designed for use with embedded devices, and is compatible with
DO-178B.  Every release of the public-domain SQLite is tested using TH3,
and so all users benefit from the TH3 tests.  But the TH3 tests are not
themselves public.  Hardware or system manufactures who want to have
TH3 test run on their systems can negotiate a service agreement to have
the SQLite Developers run those tests.</p>

<h2>About The SQLite Team</h2>

<p>Paid support options and products are provided by
Hipp, Wyrick &amp; Company, Inc., (Hwaci), a 
<a href="http://en.wikipedia.org/wiki/Georgia_(U.S._state)">Georgia</a>

so that it can be used as a learning aid or as template for building
other VFSes or for porting SQLite to new operating systems.

<li><p>
[http://www.sqlite.org/src/doc/trunk/src/test_quota.c | test_quota.c] - 
This file implements a shim called "quota" that enforces cumulative
file size limits on a collection of database files.  An auxiliary
interface is used to define "quota groups".  A quota group is a
set of files (database files, journals, and temporary files) whose
names all match a [GLOB] pattern.  The sum of the sizes of all files
in each quota group is tracked, and if that sum exceeds a threshold
defined for the quota group, a callback function is invoked.  That
callback can either increase the threshold or cause the operation
that would have exceeded the quota to fail with an 
[SQLITE_FULL] error.  One of the uses of this shim is used to enforce 

  }

  return $ret
}

proc main {} {
  global A
  set A(s) d
  cgi_parse_args

  # If "env=1" is specified, dump the environment variables instead
  # of running any search.
  if {[info exists ::A(env)]} { return [cgi_env_dump] }
  
  # If "admin=1" is specified, jump to the admin screen.