96496adb611ced49ed1c2c778c616d1f8a5d0e6b |
|
23-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Provide an API for enabling foreign key constraints. Also provide a lifecycle method on SQLiteOpenHelper so that applications can configure things like this before the onCreate, onUpgrade, onDowngrade and onOpen callbacks run. Change-Id: If3d1396720bd2e032dd9e034733fb1ff9a9733dd
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
47847f3f4dcf2a0dbea0bc0e4f02528e21d37a88 |
|
23-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Support enabling WAL using a flag when DB is opened. Using enableWriteAheadLogging() to enable WAL is inefficient because we previously disabled WAL mode when the database was opened. Switching from WAL to PERSIST then back to WAL is inefficient and could slow down application launch time. It would be better to leave the database in WAL mode when we open it to begin with. To do that, we need to know ahead of time whether we will want to have WAL enabled for the newly opened database. Using this flag also reduces the chance that we will encounter an error enabling WAL mode due to there being other open connections to the database. Bug: 6124556 Change-Id: I38ec7a528baeda9f1ef77e25e88b3ca4b6296200
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
559d0645ac8f80491671fa5d3c63e8f296f2909e |
|
29-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor SQLiteOpenHelper. Combine the code for opening readable and writable databases. This improves the handling of the case where a database cannot be opened because it cannot be upgraded. Previously we would open the database twice: first read-write, then read-only, each time failing due to the version check. Now only open it once. Removed the goofy locking logic related to upgrading a read-only database to read-write. We now do it in place by reopening the necessary connections in the connection pool. Change-Id: I6deca3fb90e43f4ccb944d4715307fd6fc3e1383
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
1c423b81deda88cffdf27c4b0aafc0f4daf3ac8f |
|
18-Jan-2012 |
Pin Ting <pinting@google.com> |
Fixes some javadoc. Change-Id: I4ad1f1452e2c8e004865853247e0b34b78bb1616
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
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
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
661cd52e0e1d527132eb1cae604d3e64da7ec0cb |
|
22-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Add progress dialog for booting after an upgrade. This introduces a new facility for code during the boot process to display messages to the user through a progress dialog. This is only for use when performing longer-than-usual post-upgrade operations such as running dexopt on applications or upgrading databases. Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
a5af5d6b122b5d7337e6640deabf7886689679eb |
|
13-Dec-2010 |
Eric Hassold <hassold@google.com> |
Add support for downgrading database version in SQLiteOpenHelper Provide an API to allow application to support downgrade in databases managed with SQLiteOpenHelper. Since onUpgrade() is now called only if requested version is newer than current one, this adds support for a similar onDowngrade() method, so customers can implement graceful downgrading. If no downgrade method is implemented by caller, this fallback to current behavior by throwing an exception. Bug: 1609474 Change-Id: I0e0166984d4a700b1c43ce780b91244bc2fc87a6
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
cc6f54910d2431e31af176163f61b34d50a33647 |
|
24-Aug-2010 |
Vasu Nori <vnori@google.com> |
SQLiteOpenHelper should discard closed singleton database objects bug:2943028 Change-Id: I4b6263cc25413995363158c976d3c723231cc050
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
c3a8c8a767acdcb66b4a80401224f977ab82348e |
|
28-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
am a4ab2651: am 4d544376: am 86c035f0: Merge "COMMENT ONLY change to clarify ContentProvider documentation." into froyo Merge commit 'a4ab26513426bf86c51c3c9419efb148be3aca8e' * commit 'a4ab26513426bf86c51c3c9419efb148be3aca8e': COMMENT ONLY change to clarify ContentProvider documentation.
|
4d5443762bd2b44b28edc2f2f75728911d70eac1 |
|
28-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
am 86c035f0: Merge "COMMENT ONLY change to clarify ContentProvider documentation." into froyo Merge commit '86c035f0d176be9cb06b1e4f2390c25701417586' into gingerbread * commit '86c035f0d176be9cb06b1e4f2390c25701417586': COMMENT ONLY change to clarify ContentProvider documentation.
|
6fcc0f073d8583cf1f485b9548cde41336a422be |
|
28-Jul-2010 |
Dan Egnor <egnor@google.com> |
COMMENT ONLY change to clarify ContentProvider documentation. Gets a little more specific about thread behavior, and makes pointed comments about not doing too much work in onCreate(). Change-Id: I682f0eb7d7559babee901ed26642751a6ba0a1ea
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
37d33a546b9051085e3991918ab089104f1c344a |
|
08-Jun-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
am 599f7287: am 9ac3743d: Merge "Log.wtf when databases go to be downgraded." into kraken
|
44dc76a8a702d6a919fcea1c2d19ba3792687c85 |
|
03-Jun-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Log.wtf when databases go to be downgraded. BUG=2734435 Change-Id: I686d6d9415f3081544c3fbe379287c31e0ecec20
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
74f170f9468d3cf6d7d0ef453320141a3e63571b |
|
02-Jun-2010 |
Vasu Nori <vnori@google.com> |
new API in Context. on openDatabase, new param DatabaseErrorHandler add new method openOrCreateDatabase in Context.java to allow callers specify a DatabaseErrorHandler object to be used when database corruption occurs. add new constructor in SQLiteOpenHelper to accept DatabaseErrorHandler as an additional param to be used when SQLiteDatabase instance is created. Change-Id: I912a0202a74510f9ca0206dd8101c4abab9102ae
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
20f549fd2f40db524242c9038d7d63356adf95fc |
|
15-Apr-2010 |
Vasu Nori <vnori@google.com> |
several minor bugs and things listed below bug:1648729 print warning if a requery is attemped on main thread bug:2459293 browser death because of NoSuchElementException. don't use iterator to march thru the ArrayList. use old style for() loop. bug:1609474 don't allow downgrades of databases other stuff use LRUcache to maintain statement-cache in SQLiteDatabase Change-Id: I3a42022162f4dfcc75f7d0cfcad8f20f1d193249
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/database/sqlite/SQLiteOpenHelper.java
|