sysreq.html

sqlite3源码,适合作为嵌入式（embedded）

<p>The developers of SQLite believe that "thread-safe" is a
  self contradiction.  No application that includes multiple threads
  of control within the same address space is every truly "safe".
  And yet it is recognized that many developers want to
  create multithreaded applications and to use SQLite in those
  applications.  Therefore, SQLite is engineered to be "thread-safe".
</p></dd>

<dt><b><a name="S40200"></a>
S40200</b></dt>
<dd><p>
The SQLite library shall support multiple independent database
connections per thread and per process.
</p></dd>

<dt><b><a name="S40300"></a>
S40300</b></dt>
<dd><p>
The SQLite library shall automatically control access to common
databases from different connections in different threads or processes.
</p>
<p>SQLite uses both internal mutexes and external file locking to 
  ensure that two or more threads or processes working
  on the same database file play nicely with one another.
</p></dd>

<dt><b><a name="S40400"></a>
S40400</b></dt>
<dd><p>
The SQLite library shall notify the application if an operation can
not be completed due to concurrent access constraints.
</p></dd>

<dt><b><a name="S40410"></a>
S40410</b></dt>
<dd><p>
The SQLite library shall provide interfaces to assist the application
in responding appropriately when an operation can
not be completed due to concurrent access constraints.
</p>
<p>If an SQL statement cannot be completed because another process is
  holding a lock on the database, then the application needs to be able
  to take corrective action, such waiting for the lock to clear.
</p></dd>

<dt><b><a name="S50000"></a>
S50000</b></dt>
<dd><p>
The SQLite library shall be cross-platform.
</p>
<p>Cross-platform in this context means that the SQLite 
  can be used on a wide variety of operating systems and processors,
  ranging from small, special-purpose embedded systems, to workstations,
  to servers.  Platforms can be 32- or 64-bit, big-endian or little-endian.
  Cross-platform refers to the source code.  Obviously the SQLite would
  need to be recompiled in order to run on processors with different
  instruction sets.
</p></dd>

<dt><b><a name="S50100"></a>
S50100</b></dt>
<dd><p>
The SQLite library shall be implemented in ANSI-C.
</p>
<p>C has been called the "universal assembly language".
  Nearly all computer systems accept code written in C.
  Thus, to help make SQLite cross-platform:
</p></dd>

<dt><b><a name="S50200"></a>
S50200</b></dt>
<dd><p>
The SQLite library shall support text encoded as UTF-8,
UTF-16le, or UTF-16be.
</p></dd>

<dt><b><a name="S50300"></a>
S50300</b></dt>
<dd><p>
SQLite database files shall be processor and byte-order independent.
</p>
<p>An SQLite database file can be freely moved between machine
  with different operating systems, different processors,
  different size integers, and different byte orders.  The same
  database file should work on any machine.
</p></dd>

<dt><b><a name="S60000"></a>
S60000</b></dt>
<dd><p>
The SQLite library shall provide introspection capabilities to the
application.
</p>
<p>Some applications need to be able to discover characteristics of
  their environment at run-time and to make appropriate adjustments to
  their processing to accommodate the environment they find themselves in.
  SQLite attempts to support this need.
</p></dd>

<dt><b><a name="S60100"></a>
S60100</b></dt>
<dd><p>
The SQLite library shall provide interfaces that an application can
use to discover fixed, compile-time characteristics of the
SQLite library.
</p>
<p>Some applications are designed to work with different versions
  of SQLite which may or may not enable selected features.  For example,
  SQLite can be compiled to be threadsafe or not.  The threadsafe version
  works in multi-threaded applications.  The non-threadsafe build runs
  faster.  When an application is using an unknown version of SQLite
  it is important that it be able to determine the characteristics of
  the particular SQLite build it is using.
</p></dd>

<dt><b><a name="S60200"></a>
S60200</b></dt>
<dd><p>
The SQLite library shall provide interfaces that an application can
use to find run-time performance characteristics and status of the
SQLite library.
</p></dd>

<dt><b><a name="S60300"></a>
S60300</b></dt>
<dd><p>
The SQLite library shall provide interfaces that permit an application
to query the schema of a database.
</p></dd>

<dt><b><a name="S60400"></a>
S60400</b></dt>
<dd><p>
The SQLite library shall provide interfaces that allow an application
to monitor sequence of queries and progress of submitted to SQLite.
</p></dd>

<dt><b><a name="S60500"></a>
S60500</b></dt>
<dd><p>
The SQLite library shall provide interfaces that allow an application
to discover the algorithms that SQLite has chosen to implement specific
SQL statements.
</p></dd>

<dt><b><a name="S60600"></a>
S60600</b></dt>
<dd><p>
The SQLite library shall provide interfaces that allow an application
to discover relationships between SQLite objects.
</p>
<p>SQLite objects are often related.  For example, every prepared
  statement is associated with a database connection.  And every
  function context is associated with a prepared statement.  
  Applications and extensions frequently find it useful to be able
  to discover these relationships at runtime.
</p></dd>

<dt><b><a name="S70000"></a>
S70000</b></dt>
<dd><p>
The SQLite library shall provide interfaces that promote the safe
construction and processing of SQL statements and data from
untrusted sources.
</p>
<p>Many applications need to be able to safely process data or
  even SQL statements that are received from untrusted sources.
  An "SQL Injection Attack" occurs when an adversary intentionally
  introduces data that is designed to have undesirable side effects
  on the database files.  For example, suppose an application generates
  an INSERT statement as follows:</p>

  <blockquote><pre>
  snprintf(z, n, "INSERT INTO table1 VALUES('%s')", zUserData);
  </pre></blockquote>

  <p>If a hostile user supplies data that reads:</p>

  <blockquote><pre>
  beginning'); DELETE FROM table1; INSERT INTO table1 VALUES('
  </pre></blockquote>

  <p>Then the constructed INSERT statement would be transformed into
  three statements, the second of which is an undesired deletion of
  all prior content from the table.  SQLite contains interfaces that
  are designed to help applications avoid SQL injection attacks and
  similar problems.
</p></dd>

<dt><b><a name="S70100"></a>
S70100</b></dt>
<dd><p>
The SQLite library shall provide the application means by which the
application can test and enforce compliance with database access
policies for any particular SQL statement.
</p>
<p>Some applications (for example
  <a href="http://www.cvstrac.org/">CVSTrac</a> and
  <a href="http://www.fossil-scm.org/">Fossil</a>) will run SELECT
  statements entered by anonymous users on the internet.  Such 
  applications want to be able to guarantee that a hostile users does
  not access restricted tables (such as the PASSWORD column of the USER
  table) or modify the database in any way.  SQLite supports the ability
  to analyze an arbitrary SQL statement to insure that it does not
  perform undesired operations.
</p></dd>

<dt><b><a name="S70200"></a>
S70200</b></dt>
<dd><p>
The SQLite library shall provide interfaces that test to see if an
SQL statement being received incrementally is complete.
</p>
<p><p>Applications such as the command-line interface (CLI) for SQLite
  will prompt the user to enter SQL statements and will evaluate those
  statements as they are entered.  But sometimes an SQL statement spans
  multiple lines.  The CLI needs to know to issue a continuation prompt
  and await additional input if the input received so far is incomplete.
  SQLite supports interfaces that allow the CLI and similar applications
  to know if the input it has gathered so far is complete or if it needs
  to await additional input before processing the SQL.
</p></dd>

<dt><b><a name="S70300"></a>
S70300</b></dt>
<dd><p>
The SQLite library shall support prepared statement objects with
late parameter binding
</p>
<p>The concept of a "prepared statement" allows an SQL statement to be
  parsed and compiled once and then reused many times.  This is a performance
  advantage in many applications.  In addition, binding values to variables
  in the prepared statement is safer than embedding values as literals because
  bound values do not need to be quoted in order to avoid an SQL injection
  attack.
</p></dd>

<dt><b><a name="S80000"></a>
S80000</b></dt>
<dd><p>
SQLite shall exhibit ductile failure characteristics
</p>
<p>A common characteristic of digital systems (as opposed to analog
  systems) is that digital systems tend to be brittle.  In other words,
  digital systems tend to work perfectly with no sign of stress until 
  they fail utterly and completely.  The behavior is like a
  physical object that holds its shape as external
  loads increase, until it shatters without warning.</p>

  <p>In most circumstances, ductile failure is preferred over brittle
  failure.  A ductile device begins showing signs of
  trouble well in advance of failure.  Physical objects bend and/or crack,
  providing operators with warnings of overload and an opportunity
  to take corrective action, while continuing to function for as long
  as possible.</p>

  <p>Digital systems have a reputation for being brittle, yet brittleness
  is not an intrinsic property of digital systems.  Digital systems can
  be designed to continuing functioning outside their design parameters
  while providing operators with warning of possible trouble.  But there
  most be focused effort on the part of the designers to make digital
  systems ductile.  With analog systems, the ductileness tends to be
  inherent in the medium, but with digital systems ductileness needs
  to be explicitly added.
</p></dd>

<dt><b><a name="S80100"></a>
S80100</b></dt>
<dd><p>
SQLite shall make anomalies visible to the application
</p>
<p>SQLite strives to deal gracefully with anomalous behavior by
  the application or by its own internal subsystems.  Yet graceful
  handling of out-of-band inputs is of no value if the anomaly goes
  unreported.  The problems must be visible to the
  application so that warnings and alarms can be propagated to operators.
  The useful aspect of ductile failure is that it gives advance warning.
  Ductile behavior is of no use to anyone if nobody can see the part
  bending.
</p></dd>

</dl>
<hr><small><i>
This page last modified 2008/12/09 22:42:03 UTC
</i></small></div></body></html>