History log of /frameworks/base/core/java/android/database/sqlite/SQLiteQueryBuilder.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
a7771df3696954f0e279407e8894a916a7cb26cc 08-May-2012 Jeff Brown <jeffbrown@google.com> Move CancellationSignal to android.os package.

Bug: 6427830
Change-Id: I39451bb1e1d4a8d976ed1c671234f0c8c61658dd
4c1241df8f8b7fd5ec3dff6c7e0f66271248e76e 03-Feb-2012 Jeff Brown <jeffbrown@google.com> Rename CancellationSignal using preferred spelling.

Bug: 5943637
Change-Id: I12a339f285f4db58e79acb5fd8ec2fc1acda5265
75ea64fc54f328d37b115cfb1ded1e45c30380ed 26-Jan-2012 Jeff Brown <jeffbrown@google.com> Implement a cancelation mechanism for queries.

Added new API to enable cancelation of SQLite and content provider
queries by means of a CancelationSignal object. The application
creates a CancelationSignal object and passes it as an argument
to the query. The cancelation signal can then be used to cancel
the query while it is executing.

If the cancelation signal is raised before the query is executed,
then it is immediately terminated.

Change-Id: If2c76e9a7e56ea5e98768b6d4f225f0a1ca61c61
e5360fbf3efe85427f7e7f59afe7bbeddb4949ac 01-Nov-2011 Jeff Brown <jeffbrown@google.com> Rewrite SQLite database wrappers.

The main theme of this change is encapsulation. This change
preserves all existing functionality but the implementation
is now much cleaner.

Instead of a "database lock", access to the database is treated
as a resource acquisition problem. If a thread's owns a database
connection, then it can access the database; otherwise, it must
acquire a database connection first, and potentially wait for other
threads to give up theirs. The SQLiteConnectionPool encapsulates
the details of how connections are created, configured, acquired,
released and disposed.

One new feature is that SQLiteConnectionPool can make scheduling
decisions about which thread should next acquire a database
connection when there is contention among threads. The factors
considered include wait queue ordering (fairness among peers),
whether the connection is needed for an interactive operation
(unfairness on behalf of the UI), and whether the primary connection
is needed or if any old connection will do. Thus one goal of the
new SQLiteConnectionPool is to improve the utilization of
database connections.

To emulate some quirks of the old "database lock," we introduce
the concept of the primary database connection. The primary
database connection is the one that is typically used to perform
write operations to the database. When a thread holds the primary
database connection, it effectively prevents other threads from
modifying the database (although they can still read). What's
more, those threads will block when they try to acquire the primary
connection, which provides the same kind of mutual exclusion
features that the old "database lock" had. (In truth, we
probably don't need to be requiring use of the primary database
connection in as many places as we do now, but we can seek to refine
that behavior in future patches.)

Another significant change is that native sqlite3_stmt objects
(prepared statements) are fully encapsulated by the SQLiteConnection
object that owns them. This ensures that the connection can
finalize (destroy) all extant statements that belong to a database
connection when the connection is closed. (In the original code,
this was very complicated because the sqlite3_stmt objects were
managed by SQLiteCompiledSql objects which had different lifetime
from the original SQLiteDatabase that created them. Worse, the
SQLiteCompiledSql finalizer method couldn't actually destroy the
sqlite3_stmt objects because it ran on the finalizer thread and
therefore could not guarantee that it could acquire the database
lock in order to do the work. This resulted in some rather
tortured logic involving a list of pending finalizable statements
and a high change of deadlocks or leaks.)

Because sqlite3_stmt objects never escape the confines of the
SQLiteConnection that owns them, we can also greatly simplify
the design of the SQLiteProgram, SQLiteQuery and SQLiteStatement
objects. They no longer have to wrangle a native sqlite3_stmt
object pointer and manage its lifecycle. So now all they do
is hold bind arguments and provide a fancy API.

All of the JNI glue related to managing database connections
and performing transactions is now bound to SQLiteConnection
(rather than being scattered everywhere). This makes sense because
SQLiteConnection owns the native sqlite3 object, so it is the
only class in the system that can interact with the native
SQLite database directly. Encapsulation for the win.

One particularly tricky part of this change is managing the
ownership of SQLiteConnection objects. At any given time,
a SQLiteConnection is either owned by a SQLiteConnectionPool
or by a SQLiteSession. SQLiteConnections should never be leaked,
but we handle that case too (and yell about it with CloseGuard).

A SQLiteSession object is responsible for acquiring and releasing
a SQLiteConnection object on behalf of a single thread as needed.
For example, the session acquires a connection when a transaction
begins and releases it when finished. If the session cannot
acquire a connection immediately, then the requested operation
blocks until a connection becomes available.

SQLiteSessions are thread-local. A SQLiteDatabase assigns a
distinct session to each thread that performs database operations.
This is very very important. First, it prevents two threads
from trying to use the same SQLiteConnection at the same time
(because two threads can't share the same session).
Second, it prevents a single thread from trying to acquire two
SQLiteConnections simultaneously from the same database (because
a single thread can't have two sessions for the same database which,
in addition to being greedy, could result in a deadlock).

There is strict layering between the various database objects,
objects at lower layers are not aware of objects at higher layers.
Moreover, objects at higher layers generally own objects at lower
layers and are responsible for ensuring they are properly disposed
when no longer needed (good for the environment).

API layer: SQLiteDatabase, SQLiteProgram, SQLiteQuery, SQLiteStatement.
Session layer: SQLiteSession.
Connection layer: SQLiteConnectionPool, SQLiteConnection.
Native layer: JNI glue.

By avoiding cyclic dependencies between layers, we make the
architecture much more intelligible, maintainable and robust.

Finally, this change adds a great deal of new debugging information.
It is now possible to view a list of the most recent database
operations including how long they took to run using
"adb shell dumpsys dbinfo". (Because most of the interesting
work happens in SQLiteConnection, it is easy to add debugging
instrumentation to track all database operations in one place.)

Change-Id: Iffb4ce72d8bcf20b4e087d911da6aa84d2f15297
9f66c650b0af7efc2d5981a1dd39779d0235c195 02-Jun-2011 Daniel Lehmann <lehmannd@google.com> Remove the obsolete function that is not used anymore

Change-Id: I749d4bdba68edb87fe7eb24095e70b544da00c71
50b1f8d3fc1379339119933e8f567547efb89aa5 02-Jun-2011 Daniel Lehmann <lehmannd@google.com> Enable strict mode as a public api to catch sql injections

Bug: 4368912
Change-Id: Ia4919f58cc5264da8758d6cd61d93e031676b74a
f4072fcc14ec44072d31d7beeb4524550bead531 18-Nov-2010 Jean-Baptiste Queru <jbq@google.com> resolved conflicts for merge of 8fc378f9 to gingerbread-plus-aosp

Change-Id: I938c0a66ad4271b33626d6b12406a2f6c6d1b6d8
84029037239fec6e54327519c3e5ad30088c28ce 12-Nov-2010 Jonas Schwertfeger <jschwertfeger@gmail.com> Added buildQuery and buildUnionSubQuery methods without misleading selectionArgs parameter.

The signatures of the existing buildQuery and buildUnionSubQuery methods include a selectionArgs
parameter that is not actually being used in the method implementations. This parameter leads
to the misconception that SQL paramter substitution is carried out by these methods. I added
new variants of these methods without that parameter and deprecated the old variants.

Change-Id: I1bf770d5c777649e9aac36d93aa93bd65bbcc2a3
40eb4aad2bbf88abe21f5868cc09d49ee1b05bf8 15-Apr-2010 Dmitri Plotnikov <dplotnikov@google.com> Introducing "strict project map".

Change-Id: I147e10ac6475badf1d21e2c27d1cedbb27bd49df
ae6cdd12ac7ded629971206efde331361604d442 14-Mar-2010 Brad Fitzpatrick <bradfitz@android.com> Allocate SQLiteQueryBuilder's WHERE clause StringBuilder lazily.

Number of callers weren't using this, and seemed like a waste to
allocate it when unnecessary.

Change-Id: Iebb701a9eb4f1d9d028bfe74463574f84a36729c
158d83054fdb449b4d23317d7b159b76f7ef76a5 27-May-2009 Android (Google) Code Review <android-gerrit@google.com> am a64f5f61: Merge change 1124 into donut

Merge commit 'a64f5f61677cf4aa3bf871c87be950bb85c2aeeb'

* commit 'a64f5f61677cf4aa3bf871c87be950bb85c2aeeb':
Fix SQLite limit issue.
ab18d1f46a0501f9a54da1ef08ff4967f4b63b68 07-May-2009 Owen Lin <owenlin@google.com> Fix SQLite limit issue.

SQLLite limit is not only used to limit the returned number of data.
It can be used to do an offset query.

For example, "SELECT * FROM table LIMIT 100, 10", will return the
data of index in the range of [100, 100 + 10).

This change set enable this kind of useage.

This is also more efficient than use "cursor.moveToPosition()".
In my experiment, I query 1000 items in batch mode, i.e.,
get 20 items out of 1000 each time.

Time of using LIMIT clause: 626ms
Time of useing "cursor.moveToPosition()": 2062ms
090d32b27509b1885eead49a4978b2dfd607639a 29-Apr-2009 Android (Google) Code Review <android-gerrit@google.com> am 9ae8873: Merge change 617 into donut

Merge commit '9ae8873ed83035e8527526e2cc1a189caf0e8d9e'

* commit '9ae8873ed83035e8527526e2cc1a189caf0e8d9e':
Allow caller-supplied column aliases in queries even when a projection map is used.
99c4483cd77ff96c5181fda3d6e2fcf2ea50421b 28-Apr-2009 Michael Chan <mchan@android.com> Allow caller-supplied column aliases in queries even when a projection map is used.

Modified SQLiteQueryBuilder to allow caller-spplied column alias ("AS")
instead restricting to the keys of the supplied projection map. This is needed for
UNION queries where new columns may be created on the fly such as "1 AS flag"
accbadeb52eda2d972fa6d9f41ebaf9168dc343a 19-Dec-2008 Yusuke Ohmichi(maimuzo) <maimuzo@gmail.com> fix issue #1587
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
54b6cfa9a9e5b861a9930af873580d6dc20f773c 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution