| c74ee2f8d3a9f4ebd502c037623cdbaf664c28a9 |
|
24-Mar-2017 |
Mike Tsao <miket@google.com> |
Replace possibly-expensive size() == 0 with isEmpty()
Bug: 36596458
Change-Id: Ieb0ea65be056bb8ce0613280e6213c330fbf783c
Test: added ContentValuesTest
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 1e20208d90b2e83f168cf569dab8ba9274a89153 |
|
31-Aug-2016 |
Mark Lu <marklu@google.com> |
docs: Update docs for SQLiteDatabase replace methods
- Mention that if the row does not exist, the method performs insert
- Add parameter info for initialValues. It was incomplete
Bug: 2321632
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| c240b607f78a50064ba2866e43e8380bfe5383bc |
|
14-Mar-2013 |
Steve Pomeroy <steve@staticfree.info> |
Fix documentation bug in SQLiteDatabase
The documentation incorrectly states that, "[insertWithOnConflict
returns] the primary key of the existing row if the input param
'conflictAlgorithm' = CONFLICT_IGNORE". Unfortunately, SQLite does
not provide such functionality.
Close: https://code.google.com/p/android/issues/detail?id=13045
Signed-off-by: Steve Pomeroy <steve@staticfree.info>
(cherry picked from commit 8fc3144fa5d9fe3a6c7fb6de80cb34d5cafabc05)
Change-Id: I89e56428e612d667259744e2bc3df124e5a2aa0e
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 17aa1b7ac799e308e3724f8c4170620c846dcc09 |
|
16-Dec-2015 |
Makoto Onuki <omakoto@google.com> |
Add SQLiteDatabase.validateSql()
This API checks the SQL syntax by compiling it. This is useful to
detect SQL injection, for example.
Change-Id: I956548a34f664950246856966e5601dcac3daf00
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| fce5890a11b421532568d9838ae3dd5836acead8 |
|
24-Jan-2014 |
Jeff Brown <jeffbrown@google.com> |
Fix NPE in deleteDatabase().
If the directory containing the database does not exist then
listFiles() will return null. Tolerate this situation instead
of crashing.
Bug: 12600784
Change-Id: I5d83a867a5e8478f50887e5798b42c5f6859b77c
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| fd02074fdd12039e905a515941ffd9a757f671c2 |
|
22-Jan-2013 |
Tim Roes <tim.roes88@googlemail.com> |
Complete documentation of whereArgs (Issue #43061)
Complete the missing documentation for the
whereArgs argument in delete, update and
updateWithOnConflict
Update: Removed trailing spaces
Change-Id: I451ec9e0747c7655c612a4506f40152af0adcf3a
Signed-off-by: Tim Roes <tim.roes88@googlemail.com>
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| a7771df3696954f0e279407e8894a916a7cb26cc |
|
08-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Move CancellationSignal to android.os package.
Bug: 6427830
Change-Id: I39451bb1e1d4a8d976ed1c671234f0c8c61658dd
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 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/SQLiteDatabase.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/SQLiteDatabase.java
|
| df78cd5ee959f57c35dd9d6ad0f6871c72438f3c |
|
22-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Work around problems changing the database journal mode."
|
| d67c8c67899481682657d41a61f3846b8d77d165 |
|
22-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Work around problems changing the database journal mode.
Because we always disable WAL mode when a database is first opened
(even if we intend to re-enable it), we can encounter problems if
there is another open connection to the database somewhere.
This can happen for a variety of reasons such as an application opening
the same database in multiple processes at the same time or if there is a
crashing content provider service that the ActivityManager has
removed from its registry but whose process hasn't quite died yet
by the time it is restarted in a new process.
If we don't change the journal mode, nothing really bad happens.
In the worst case, an application that enables WAL might not actually
get it, although it can still use connection pooling.
Bug: 6124556
Change-Id: Ia2ffdbbc8f82721b170f3bf71bd5242dfd56d9ac
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 7364477528488b52071d58a287b888faef222a05 |
|
22-Mar-2012 |
Jean-Baptiste Queru <jbq@google.com> |
Fix typo... and build
Change-Id: Ifc3c99c1e43423d0419031c7a389738b2232c6bd
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| e67ca420e4eb6ddf8ceefeb0d9dcc47d9ca189fc |
|
22-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Throw if WAL enabled/disabled when connections are in use.
Changing WAL mode requires obtaining an exclusive lock on the
database and can only be done when there are NO other active
database connections.
Check that this is really the case, and bail with a useful
error message if an application attempts to change WAL mode while
transactions are in progress.
Expose disableWriteAheadLogging() in the API.
Change-Id: I87599de3b88c53dcd75677aefd72e40de216c2c1
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 1d9f742e001ed8280fa93fd9ba0b1125ce6d00ae |
|
15-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Port the SQLite locale setting code to Java.
Make the database opening code more robust in the case of
read-only database connections.
Check whether a PRAGMA needs to be issues before doing it.
Mostly it's harmless but it can grab a transaction on the
database unnecessarily.
Change-Id: Iab2cdc96c785e767f82966b00597e19337163f2f
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 03bd302aebbb77f4f95789a269c8a5463ac5a840 |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Don't close the database until all references released.
SQLiteDatabase.close() should call releaseReference() rather than
closing the database immediately. SQLiteDatabase should also hold
a reference to itself while performing certain operations to
ensure that they complete normally even if another thread closes
the database at the same time.
Fixed a couple of missing or redundant uses of acquireReference()
related to CursorWindows.
To be honest, the reference counting performed by SQLiteClosable should
not be needed, but we're stuck with it in the API.
Bug: 6104842
Change-Id: I3444a697409905d4a36b56418dc7766f5ba76b59
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| baefdfad6e77e772deb6474380dd85ac776293e8 |
|
05-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Make SQLiteDatabase final.
The SQLiteDatabase constructor is inaccessible so it is not
possible for applications to subclass it. To remove all possible
remaining temptation to do so, make the class final.
Change-Id: I4148e9b06f0661ec22aab8e45afde38498d2375a
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 8dc3cc2e13b500e368f5ba1aacfaf0eddbce668c |
|
02-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Allow the SQLite sync mode to be set independently for WAL.
This change leaves the sync mode at FULL for both WAL and non-WAL
but makes it easy to change it for one but not the other.
To reduce the number of synchronous writes, it might make sense to
change the sync mode for non-WAL to NORMAL instead of FULL which
should be just as safe.
On the other hand, the sync mode for WAL should probably remain FULL
because there may be an impact on transaction durability otherwise.
Initial experiments show that there might not be a significant
performance benefit to using NORMAL, but we may revisit this later.
Change-Id: Ifcd55bedcfefa6600974c2295ca5d4163b408cbf
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 79087e4b967d8af26c488c41b8c1a087a12da84d |
|
02-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Add an API for deleting databases.
Add SQLiteDatabase.deleteDatabase to delete a database and all
of its auxiliary files.
This method is also used by Context.deleteDatabase and resolves issues
where auxiliary files would get left behind.
Bug: 5972489
Change-Id: I3633b9b4978972a1d240ac0a9861420ecf989149
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 5936ff097eff2c736af2e43fd4a8f7db0ddcfb5a |
|
01-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Externalize more SQLite configuration options.
Moved more configuration into config.xml so we can tweak settings
like the default journal mode, WAL auto-checkpoint interval and
so on.
This change itself should not introduce any functional differences.
Change-Id: Id6c95fa25b116ce47e8ae49cd8a80d52b1c0dd80
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.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/SQLiteDatabase.java
|
| 4c1241df8f8b7fd5ec3dff6c7e0f66271248e76e |
|
03-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Rename CancellationSignal using preferred spelling.
Bug: 5943637
Change-Id: I12a339f285f4db58e79acb5fd8ec2fc1acda5265
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 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
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| a9be4154e8dac0de3db5ee42e878beb0639e70e6 |
|
19-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix issues with reentrant SQLite triggers.
Modified SQLiteConnection and SQLiteSession to support
reentrant execution of SQLite operations, as might occur
when a custom function is invoked by a trigger.
Bug: 5884809
Change-Id: I253d828b2801bd06b1bbda7caa7da3f040a642bb
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.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/SQLiteDatabase.java
|
| 89101cd9d9b5c1a6ff1ed85eba0613ca4c4802e2 |
|
28-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Improve the slow query instrumentation.
On user-debug and eng builds, you can set the
"db.log.slow_query_threshold" system property to queries that
take longer than the specified number of milliseconds.
Set it to 0 to log all queries.
This property has been around for a while but it was implemented
poorly. In particular, it *changed* the behavior of the query
by calling getCount() while holding the Db connection.
In normal operation, the query will not actually run until later.
By putting the timing logic into fillWindow() instead, we ensure
that we only measure queries that actually ran. We also capture
cases where the cursor window gets filled multiple times.
Bug: 5520301
Change-Id: I174f5e1ea15831a1d22a36e9a804d7755f230b38
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 270928bd4a1db1dc0d989f4e9897a81ab865e30e |
|
08-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge changes Idbfeb3cc,I03e8e2e7,Iff9eed78
* changes:
Fix regression in CursorWindow.getString() Bug: 5332296
Clean up CursorWindow lifetime. Bug: 5332296
Fix regression in CursorWindow.copyStingToBuffer. Bug: 5332296
|
| 7ce745248d4de0e6543a559c93423df899832100 |
|
07-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Clean up CursorWindow lifetime.
Bug: 5332296
Removed dead code in SQLiteCursor related to the use of a background
query thread. This code could result in CursorWindows being modified
concurrently or used after free. This code is broken, unused and
is just in the way.
Added comments to explain how CursorWindow ownership is
supposed to work for AbstractWindowedCursors. (There are still cases
where cursor windows get dropped on the floor without being closed.
Those will be taken care of in a subsequent patch.)
Cleaned up SQLiteQuery.fillWindow to eliminate duplicate code and
remove bits that were only needed for background loading, like
returning -1.
Change-Id: I03e8e2e73ff0c11df76d63f57df4c5ada06ae1cb
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| ad9e8b1a87edc8009ff60932a22fead1df944089 |
|
06-Oct-2011 |
Christopher Tate <ctate@google.com> |
Disable db_sample logging
db_sample logging is thrashing the event log hard, and is currently
neither maintained nor heeded by anybody on the current release. It
can be re-enabled simply by throwing the appropriate static boolean
to 'true', but for now this should greatly improve the utility of our
event logs. (We were seeing a rollover period of 20 minutes or less;
ideally we want to see the event log run at least half a day before
rolling.)
Bug 5419627
Bug 5104300
Change-Id: I2125544130aae142974102dbad3b557e49fcd494
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 43a17654cf4bfe7f1ec22bd8b7b32daccdf27c09 |
|
07-Apr-2011 |
Joe Onorato <joeo@google.com> |
Remove the deprecated things from Config.java. These haven't been working since before 1.0.
Change-Id: Ic2e8fa68797ea9d486f4117f3d82c98233cdab1e
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| cc1eaf6f7b81eaae21c01cbf4cf6f27dc3970774 |
|
15-Mar-2011 |
Vasu Nori <vnori@google.com> |
bug:4090903 allow bindargs on attach database statement
code incorrectly assumed that certain statements (like ATTACH DATABASE)
will never have bindargs.
Change-Id: I62eddbdf8e15947e8debf5052c7248113a3b9b57
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 16057fad00d47e920fc20721b70c7cafb765f7f8 |
|
18-Mar-2011 |
Vasu Nori <vnori@google.com> |
fix broken logTimeStat stuff
log time in the following 2 situations
1. all transactions. time measured = wall time between begin-commit
2. queries (which are not in tranactions)
Change-Id: I67be9487a96072695aff3529ba4a257f4c8ec596
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 32c80a27dae4a3094f647bb4d97b27a0eb3b985e |
|
26-Feb-2011 |
Jesse Wilson <jessewilson@google.com> |
Handle rename of LruCache.entryEvicted to entryRemoved
Change-Id: I50e5a8d8c35c4431f42c7483172447ba0e4e125b
http://b/3461302
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| dae6d3705d34a45a4ffe2fe411e6de644ef78e47 |
|
17-Feb-2011 |
Paul Westbrook <pwestbro@google.com> |
Revert "turn off sqlite WAL until bugs bug:3024421 and bug:3353077 are fixed"
This reverts commit d67dbeeb322eac08681fab5be09d30f9663cc128.
This reenables WAL in the framework. We are tracking down the cause of
the problems with WAL
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| c5d0fbbfdf91acdbc58f01e033e2e59093ef3e8a |
|
12-Feb-2011 |
Vasu Nori <vnori@google.com> |
Merge "add more debug info to help (bug:3446432)"
|
| e9714e6c745a2bd7103d793c3473bbddf2c46712 |
|
12-Feb-2011 |
Vasu Nori <vnori@google.com> |
add more debug info to help (bug:3446432)
Change-Id: I4a690297ae7f18d5f6928ac5c67d8d4164453fa0
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| dfe515e49ae8a0275012b56a4a79d2dfcc017db2 |
|
11-Feb-2011 |
Jesse Wilson <jessewilson@google.com> |
Remove LruCache.setMaxSize().
Dynamically changing a max cache size is clumsy; almost everyone
should set this when they create the cache.
Fix SQLiteDatabase to copy entries into a new cache when the size
is changed. In pratice this will always be immediately after the
SQLiteDatabase is created. Since the cache field is no longer
final, change the guard on the cache field to the SQLiteDatabase
instance itself.
Change-Id: I4e325f06edc551636723568a52770c0982e2d945
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| c2c9a2492cc99e20d23d2d92df061f35a8b14304 |
|
11-Feb-2011 |
Jesse Wilson <jessewilson@google.com> |
Don't add setMaxSize() to the LruCache API. But do add maxSize().
Change-Id: I9697ab29491dabe85c2400defdde16b9abcd003a
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 9b5a93550f3853b229ae9cfb5f6cf33091478023 |
|
10-Feb-2011 |
Jesse Wilson <jessewilson@google.com> |
Adopt LRU cache in SQLite.
Change-Id: I6b43dd8843d41726254bea3a175fe28f5f061ed7
http://b/3184897
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| d67dbeeb322eac08681fab5be09d30f9663cc128 |
|
09-Feb-2011 |
Vasu Nori <vnori@google.com> |
turn off sqlite WAL until bugs bug:3024421 and bug:3353077 are fixed
they are becoming pretty disruptive bugs.
many more instances of gmail crashing with locking protocol error.
and a positive identification of WAL as the problem in Music app
AND one instance of gmail crash that I know of.
who knows how many folks are NOT reporting the gmail crash.
too bad we relied on pre-released version sqlite feature
without seeing it complettly tested in the field.
not a safe feature to turn on at this point in time.
maybe more testing and debugging in Ice timeframe.
Change-Id: I283ad26ba7e1793772a372aa8e24df0cb96ce2ef
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| d4608a35e89c2604194b314ff9babb07ba8a14e1 |
|
04-Feb-2011 |
Vasu Nori <vnori@google.com> |
while waiting for lock, try in 30sec intervals and print warnings if no lock
should help a little bit in debugging deadlocks in the process.
especially when the an application does this:
thread1: begin transaction
thread2: synchronized void blahMethod { do some code; begintransaction;}
thread1: with lock ion the database, it now tries to get into the above
synchronized method
thread2 has synchronized monitor and thred1 has db lock.
each wants the other lock
deadlock.
and our stacktraces will not tell us that thread1 has the database lock.
with this CL, we will know WHO owns the database lock and which thread
dies waiting for the lock.
Change-Id: If51578e7fa0a70ee3d762eb2233d1fddd98a2e86
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 83ff97d8403db4d8d0a351031f0c9efcb602a99c |
|
30-Jan-2011 |
Vasu Nori <vnori@google.com> |
bug:3385018 don't print finalizer warnings under certain conditions
Change-Id: I06c49a464f61c26d3e6645a95f2dd38d444bf384
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| a017edace756956cd4b4789a85316e3681d04a7e |
|
27-Jan-2011 |
Vasu Nori <vnori@google.com> |
bug:3398527 return List insttead of ArrayList from public API
Change-Id: Idbdcb59fe860a9168c9ef6c00eb128b05fce84ff
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 4b92aeec3faa459507f297ce49b2a2d4daaa4e47 |
|
27-Jan-2011 |
Vasu Nori <vnori@google.com> |
bug:3396894 (HC branch) remove STOPSHIP code
Change-Id: Iad8790b7c2efa3a9b35e07429ea47d4e9f72081b
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| a22d88493ea2a0cdd63b026c0d4b524d658a8e65 |
|
06-Jan-2011 |
Vasu Nori <vnori@google.com> |
set default mode of WAL to be off.
apps will have to enable WAL explicitly.
Change-Id: Iba5c47a40f465e668ef0d538282230e99fe04ce6
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 6a904bc65e5220410457b1e78a673923ea9a5767 |
|
06-Jan-2011 |
Vasu Nori <vnori@google.com> |
Revert "treat 'can't open database file error' as 'database corruption error'"
This reverts commit c7fe777d6348bd740d3f2554e9308176a0c462ed.
Change-Id: I9992d404394917537d5c22470efbd970605976ed
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 70588bf864f961974c93aace7586d3e2773a54a8 |
|
05-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
resolved conflicts for merge of 3a2c6bf0 to master
Change-Id: I1963d8fc391bb84de1054f2b20ce4e082d764cbe
|
| 69ea4e15e52c456537575d21443ac1efdb03a902 |
|
05-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
Documentation fixes found over vacation hacking.
Change-Id: I28900026465d66d950cf4f05f0c202b46c3c2d43
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| c7fe777d6348bd740d3f2554e9308176a0c462ed |
|
04-Jan-2011 |
Vasu Nori <vnori@google.com> |
treat "can't open database file error" as "database corruption error"
bug:3083665
if sqlite can't open the database, delete it and create a new one.
what else is sqlite supposed to do?
Change-Id: I8b7c3b051fd1a146e4026f8f8acfdd099f9a70cf
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 34ad57f0e844cd97f59d4ab22087d60d58650ba4 |
|
21-Dec-2010 |
Vasu Nori <vnori@google.com> |
resubmitting Change-Id: I67b1d04a5c9fc18b0cd4da6184d0b814b64d89e9
Change-Id: I67b1d04a5c9fc18b0cd4da6184d0b814b64d89e9 was reverted
due to a bug. fixed the bug and resubmitting it here
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 5274e84e88d2cba20ad3cb21c55c1758b4da8af4 |
|
20-Dec-2010 |
Vasu Nori <vnori@google.com> |
Revert "bug:2448371 cursorwindow size moved to resource xml file."
This reverts commit 2594bae1f551d758c5c88771310d1ee3dc2c71ac.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 2594bae1f551d758c5c88771310d1ee3dc2c71ac |
|
19-Dec-2010 |
Vasu Nori <vnori@google.com> |
bug:2448371 cursorwindow size moved to resource xml file.
let cursor window size be set per device in device resources file.
default is 1MB.
for SR, it is 2MB.
it can be set to any value (in kB) in the device resource
strings.xml file
Change-Id: I67b1d04a5c9fc18b0cd4da6184d0b814b64d89e9
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| b438902369ddb6785963c2bbe3d5d1d8679f7b8f |
|
29-Nov-2010 |
Vasu Nori <vnori@google.com> |
if db close() fails due to un-closed sql statements, print useful msg
The current error message says "close failed due to unfinalised statements".
This CL fixes that message by incorporating one of the un-closed sql statements
should help developers debug the problem.
Change-Id: I2a24c6ba876caa008507b236052c5f03e8cbb27e
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 00e40171892c73295b6e7221ed83126731230b98 |
|
29-Nov-2010 |
Vasu Nori <vnori@google.com> |
Revert "Merge "print certain rows from downloads.db when bugreports are taken""
This reverts commit 34878787f06c07b5cf14879254ef9abccffa631b, reversing
changes made to 5a2755d0c9220b6bc52cb1262927e27dc3dce6c1.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 624002b0d5b5bd812ca457fdfde0ead2b908eb7a |
|
22-Nov-2010 |
Vasu Nori <vnori@google.com> |
print certain rows from downloads.db when bugreports are taken
when downloads fail/get stuck, we need to look at the database state
for those downloads. and when the users report such problems, it is
a royal pain not to have that info and most users don't seem to bother
sending database dumps because it is a bit of work.
so lets just dump info about downloads that failed or
downloads from GSF (OTAs, for example)
helps debugging. there is STOP ship comment to not dump data once
HC is released.
Change-Id: Id1254982fd82b4c55f1816a2491f00966840f024
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 46a8851360de255a4a63a0bdf61987a89e1d8e73 |
|
12-Nov-2010 |
Brian Muramatsu <btmura@google.com> |
Fix NPE in SQLiteDatabase#updateWithOnConflict
Bug 3188586
...to restore old behavior of throwing IllegalArgumentException
when values is null.
Change-Id: Ic2df542b2cdbdb7571080eb7f0fc6a4fe1678446
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 8fcda30283d109fd1c3cb8a753281b90115db9c9 |
|
08-Nov-2010 |
Vasu Nori <vnori@google.com> |
on readonly databases, don't set journal mode and don't allow WAL
nothing should be 'set' on readonly databases
bug:3173033
Change-Id: I1143971f6d06139a7e1ef9e73a92e46342264075
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| b642518e54624d6667253218ab24cbb9dbd6c179 |
|
05-Nov-2010 |
Vasu Nori <vnori@google.com> |
fix broken build
Change-Id: If1e5639f48d5155e141bce4bf5deef9de5668c27
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 7301a23fb29f67ef77c07fc220cbd2da4bd41828 |
|
05-Nov-2010 |
Vasu Nori <vnori@google.com> |
Let cachefull-warning be under SQLiteDebug.DEBUG_SQL_CACHE flag
This warning doesn't really matter much. If a developer wants to
debug the cache usage, it can be done by turning on this flag.
adb bugreport also displays cachestats - which can be used as a debugging tool.
Change-Id: Ied173714d535c271133247ee4768f86d3be359cf
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 74fb2685e229b3c68d16e6f2ad6635aad69ca3b8 |
|
25-Oct-2010 |
Vasu Nori <vnori@google.com> |
when printing cache-full warning, print the sql statements in cache
this should help debug developers in idetifying the sql statements
taking up cache slots
Change-Id: Ibc0140c273adc5c8d58ab359d2c4d4ce14b6b63b
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| f0808f810ed5852c0bbde1e1764cbda9686e3f49 |
|
08-Oct-2010 |
Vasu Nori <vnori@google.com> |
when printing requery on UI warning, include additional info
this hsould help figure out which module is doing query on UI thread.
Change-Id: If3062a35fa1fb50063b678c3c9311d6b1504fa9b
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 6d970255af55443a1c9a4211be9a265408598680 |
|
05-Oct-2010 |
Vasu Nori <vnori@google.com> |
STOPSHIP - add illegalStateException to catch potential deadlocks in db
database lock() should not be called from a synchronized methods
in database layer. add code to check.
this will catch potential deadlock situations sooner
Change-Id: I9d913f5e2af304f4d9ad5b2641c3a768c4bc97f9
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 2467561ac2c7de870417e0405a138c857c9d5629 |
|
27-Sep-2010 |
Vasu Nori <vnori@google.com> |
SQLiteDatabase: fix inconsistent locking
Synchronized blocks should never call lock() or any operation that
does it. otherwise, bugs like bug:3032897 will occur.
Remove synchronization on all methods in SQLiteStatement
and SQLiteProgram because the caller is supposed to
do the synchronization if the same SQLiteStatement or
SQLiteQuery (which extends SQLiteProgram) object
is used by more than one thread at the same time.
(documentation on SQLiteStatement, SQLiteProgram
mentions this note)
Change-Id: Ifd6ee94d743c38c187e2eb778c57076da7a15073
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 587423afb52f65db28498a9f2378cccbd2e823c8 |
|
28-Sep-2010 |
Vasu Nori <vnori@google.com> |
fix this: closing database twice fails with IllegalStateException
Change-Id: Idda35e49d539845099b377872f9a6f0e0caa4626
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| ffe06127f6ea4e9ea8e797f8ba0365d1f47fe297 |
|
27-Sep-2010 |
Vasu Nori <vnori@google.com> |
remove public API setConnectionPoolSize()
because connection pool size is now settable by modifying config.xml
of the device.
Change-Id: I973cc11d7dc10c8d95ab83e2f691068f6019fa33
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 5a049b0fffd98f5b6b61e43a01345c476d27c1f7 |
|
24-Sep-2010 |
Vasu Nori <vnori@google.com> |
temporarily comment out dbstats info code when doing adb bugreport
could this be causing bugs like bug:2990184
Change-Id: I315aaa93c1d71922ad4bc96ba0a14a9261a6f39a
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 5e89ae29f0e8bf71d54360d35243da905892b168 |
|
15-Sep-2010 |
Vasu Nori <vnori@google.com> |
fix compiled statement bugs, synchronization bugs
1. when LRU cache wants to remove the eldest entry, it may be finalizing
a statement that is still in use
2. a couple of synchronization issues.
3. a bit code refactoring in SQLiteCompiledSql
4. remove a bunch of unsed debug code from SQLiteDatabase
Change-Id: I45454dc2dbadd7d8842ba77dd2b0e9ff138ec6f4
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| b83cb7cda3947fb35e126eab1530732fcd797ad0 |
|
14-Sep-2010 |
Vasu Nori <vnori@google.com> |
revert Change-Id: Ic610a0c38e7bd7c77006a08c7b82fa01957739e5
can't change return type from void to int.
Change-Id: Iec3d95c731f117aca20b29c719cef7bcc6356ac0
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 5402590f1cb8ae1bc31f796705ff6f10bc175730 |
|
14-Sep-2010 |
Vasu Nori <vnori@google.com> |
change return type from void to int on execSQL() methods
1. let execSQL() methods return the number of rows affected by the SQL
staement executed.
2. remove synchronized on 2 public methods. since public API is not
supposed to have synchronized, this was a mistake in previously submitted
CL
Change-Id: Ic610a0c38e7bd7c77006a08c7b82fa01957739e5
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| b729dcc8a94bc2c2a1ecda47d791be0d6f1d160a |
|
14-Sep-2010 |
Vasu Nori <vnori@google.com> |
Revert "caching code retooled to reduce locking + handle SMP"
This reverts commit 992f7d52fad590d90edc166cd74380e96d627605.
Change-Id: Ia5b789d1b2195d6ce43baffe24296c857f9b30f6
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 992f7d52fad590d90edc166cd74380e96d627605 |
|
03-Sep-2010 |
Vasu Nori <vnori@google.com> |
caching code retooled to reduce locking + handle SMP
1. Moved all code related to compiled-sql statement cache to SQLiteCache.java
Removed all caching related code from everywhere else.
2. Moved all code related to compiling a sql statement and caching it to
SQLiteCompiledSql.java. There was some code in SQLiteProgram.java
releated to this. moved it out.
3. Added state to SQLiteCompiledSql. This is to help in debugging.
Change-Id: I63ab0c9c4419e964eb9796d284dd389985763d83
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 422dad0f5069a96c002faf31540bf471a7052585 |
|
04-Sep-2010 |
Vasu Nori <vnori@google.com> |
android change to handle Change-Id: Idbeed81b5b7349059e467b33a8641abf0b4aaeff
Change-Id: Icf221a8e8d4c281f7719875816835ad7dfe7f3d1
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| bfe1dc27944c80dcb81f0eb313987999ecd7b6fa |
|
26-Aug-2010 |
Vasu Nori <vnori@google.com> |
fix isIntegrityCheck() & add a sample impl class and test for DatabaseErrorHandler
fixed a bug in SQLiteDatabase.isDatabaseIntegrityOk()
and added a new class to demonstrate use of
android.database.DatabaseErrorHandler
and a bunch of nits
Change-Id: Ia81870853fa3bd84074637f6d823a9fd22b66c7e
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.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/SQLiteDatabase.java
|
| 9a8bc78da74a1aecce0da7120eedd84445bb2501 |
|
23-Aug-2010 |
Vasu Nori <vnori@google.com> |
weird java bug. bug:2941509
Change-Id: I70edabbdb5c715018227958b74fa1ac4e4df3f88
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 0732f7912ccec9a1cc379b535ac0b56ae50972b3 |
|
30-Jul-2010 |
Vasu Nori <vnori@google.com> |
random but useful stuff
1. move binding of args to one place - to SQLiteProgram
2. reduce locking time in SQLiteDatabase
3. reduce locking during time of binding of args
4. rmeove test for the deprecated ArrayListCursor
5. a couple of nits here and there
Change-Id: I20c33c8ffe3325df67af655f1d20614f7f727cb7
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| ce38b98feb1e7c9c1799eb270c40798d833aa9ae |
|
22-Jul-2010 |
Vasu Nori <vnori@google.com> |
do begin-end transaction before standalone insert/update/delete sql
also fix bug# 2871037
Change-Id: I13325f8eabff4f218d3206905010803b61d8e2cd
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| fb16cbd9b2e86d6878d4bff820422bc09c8938de |
|
26-Jul-2010 |
Vasu Nori <vnori@google.com> |
add new API in SQLiteStatement to deprecate another.
1. SQLIteStatement.executeUpdateDelete() replaces execute() - and returns the
number of rows changed.
2. let SQLiteDatabase.execSQL() call the above new API - which
means all CRUD statements by execSQL() are stored in prepared statement cache.
3. remove the following from SQLiteDatabase
lastrowId
lastchangecount()
native_execSQL()
Change-Id: I4e93a09dc381f425c3ae6ccc331a7bf227491e22
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 95675137f417173dc711a2d39232a1f545799013 |
|
22-Jul-2010 |
Vasu Nori <vnori@google.com> |
deprecate synctable methods and remove associated private methods
seems this stuff is not used at all. a couple of CTS tests fail due to this code
not being corrected after recent changes to disable updates through cursor.
Change-Id: Iba87258e1c8fa18c2cc46d1d2ab56ec3e38413f2
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 65a8883f0e605bb8a73a692987b47ce5da632e72 |
|
17-Jul-2010 |
Vasu Nori <vnori@google.com> |
don't store mDatabase in SQLiteCursor as it is already in SQLiteQuery
SQLiteCursor has two members: mQuery, mDatabase
but mQuery already has mDatabase.
there is no need for SQLiteCursor.mDatabase.
and everytime SQLiteQuery.mDatabase is to be used, try to use a pooled database
connection handle, if possible.
Change-Id: I42b2376d714a1a4091c843e245a45b882bb7fee6
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 7b04c4176d9cb2f96487ad891f4cf769bccb4f1b |
|
20-Jul-2010 |
Vasu Nori <vnori@google.com> |
make disableWriteAheadLogging method public so apps can disable WAL
music2 app has the weird situation where it embeds the jumper C++ code
and that code uses its own version of sqlite.
so, java side may want to disable WAL to make c++ code work well with java
usage of sqlite.
since WAL is made default option for all apps, this CL makes it possible for
music2 app to disable WAL.
Change-Id: I39ddbc9b4648f12b206ff3e76d30341da5955bd4
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 9d9c1be296db26c6ad36b8593fb77ca263422665 |
|
14-Jul-2010 |
Mike Lockwood <lockwood@android.com> |
SQLiteDatabase: Add mechanism for registering custom sqlite3 functions
This allows you to define a callback in Java that can be called from
sqlite3 database triggers.
Change-Id: I09fdbd38c9807b6b0dd19c2761b01e8db76f1adc
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 57feb5d9a7fd5329c2ae5daeca0ce8f10a7372a7 |
|
22-Jun-2010 |
Vasu Nori <vnori@google.com> |
STOPSHIP CL in master - make sqlite WAL default for all apps
for testing the sqlite WAL feature in the next few weeks.
Change-Id: I07234647b5e90d9e3bb0a5310b6cc449d58db428
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 9bf225ef7b82b5eacee1907155a8a8bbb6aa7f42 |
|
08-Jul-2010 |
Vasu Nori <vnori@google.com> |
documentation about not using journal_mode if using WAL
apps should not setting journal_mode if the application is
using a connection pool for readers by calling the method
SQLiteDatabase.enableWriteAheadLogging()
Change-Id: I9ddb32638171c6277ca94381a1b5d4b39b92b386
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 2827d6d974beabb12344040a002dcb52dd7106b5 |
|
04-Jul-2010 |
Vasu Nori <vnori@google.com> |
for WAL to work, can't keep prepared SQL stmt_id in SQLiteStatement
Some (including the Contacts app) do the following:
1. Open database
2. As part of database_connection.onCreate(),
Create some SQLiteStatement objects to cache them in the process
3. attach databases
WAL doesn't work with attached databases. so, apps doing the above
should enable WAL only if there are no attached databases.
But we would like to enable WAL automatically for all apps after step #1 above
and disable WAL if the app subsequently does 'attach database' SQL.
this works only if there are no SQLiteStatement objects created in step # 2,
because SQLiteStatements cwmaintain a hard-reference to the database connection
for life and also to the prepared SQL statement id.
It is quite difficult to disable WAL in step # 3
if it is enabled in step # 1
and then a connection pool gets used by step # 2
would make WAL disabling easier if SQLiteStatement refers to prepared SQL
statement id only when it is needed (during binding and execute calls)
and thus NOT tied to a spacific database conenction.
also, from the standpoint of not blocking readers, it helps NOT to have
SQLiteStatement be married to a database connection and prepared SQL statement
id for life.
Change-Id: I464d57042965a28d2bde88e0f44b66ec119b40dc
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 7501010b71d57264a06f82937f5fb29cb9f4b509 |
|
02-Jul-2010 |
Vasu Nori <vnori@google.com> |
some refactoring and multi-threading fixes
Change-Id: I7a0497dc2ed7b1e21471d71532558ef243eb9f73
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 36e5f667bc889a7b1bc17f9a5bd44f33b2d47020 |
|
25-Jun-2010 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 2eb12a47 to master
Change-Id: I79eb9d9f083e51ec1b99145d81632683669e7a99
|
| 01e4cfc47d0a2c7e7ab383d2fb23224ec52c0301 |
|
25-Jun-2010 |
Dianne Hackborn <hackbod@google.com> |
Some ActivityThread/ActivityManager cleanup.
- Move PackageInfo out of ActivityThread, renaming to LoadedApk.
- Rename some of the other PacakgeInfo inner classes to better
represent what they are.
- Rename HistoryRecord to ActivityRecord.
- Introduce AppGlobals, to eventually let ActivityThread become
package scoped.
Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 8d1110383d4437eeebae337026cd91449e4e55a5 |
|
23-Jun-2010 |
Vasu Nori <vnori@google.com> |
if attach database sql statement is exec'ed, disable write WAL
an app can execute 'attach database..' statement anytime after WAL is
enabled. since WAL doesn't work with atatched databases,
disable WAL whenever the caller executes 'attach database'
sql statement.
Change-Id: I77dfcb744b59476c357d44296c14d63455985a7b
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| a98cb2632dcf07ebd8d036f61c1438f795e262cc |
|
22-Jun-2010 |
Vasu Nori <vnori@google.com> |
for memory databases, don't set journal_mode and don't allow WAL
WAL and journal_mode are not applicable to memory databases
Change-Id: I06fcbfe9ce76878c57d1542efe9cc060598262ff
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 194897da946d9e1cb068c3bf26d6b1f235cd1851 |
|
21-Jun-2010 |
Vasu Nori <vnori@google.com> |
journal_mode should be set only on non-memory databases
setting journal_mode to TRUNCATE on memory databases causes an error message
to be displayed by SQLIteDatabase.
Change-Id: Ie8b8ae22cb9fba99cee59dba35b260195c63eadc
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| daa4e4faffd025c11b2a8618409b8496a6829664 |
|
15-Jun-2010 |
Vasu Nori <vnori@google.com> |
throw correct exception
when an argument is incorrect, throw IllegalArgumentException
not IllegalStateException
Change-Id: I9a33410617ab6a00147c3ab2010ed31251983329
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| ad239ab8fabe53e5f82ff80fb8c9260386dd900c |
|
15-Jun-2010 |
Vasu Nori <vnori@google.com> |
when closing db, close all pending statements also
Change-Id: Ia543933e0cd70852c4e60623de698bb51b976900
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 6c354da9436e946708fc3f3a1c0d18b18bbfdf43 |
|
27-Apr-2010 |
Vasu Nori <vnori@google.com> |
read old version of data and use multiple connections to db
cts tests are in Change-Id: Ifcc89b4ff484c7c810fd2d450ded212a43360dda
dependency on: Change-Id: I938c42afc3fb50f5296d01c55ffcf4a102d8b0cb
1. Use sqlite's work-in-progress writeahead logging feature to read old
versions of data and thus increase concurrency of readers
even when there is a writer on the database
2. New API executeQueriesInParallel() sets up a database connecion pool
automatically created and managed by sqlite java layer
3. To increase reader concurrency, add an option to do BEGIN IMMEDIATE xaction
instead of BEGIN EXCLUSIVE
Change-Id: I3ce55a8a7cba538f01f731736e7de8ae1e2a8a1f
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| f9e2bd085f50d557ec48f4e4728fe5a79d37ede5 |
|
05-Jun-2010 |
Vasu Nori <vnori@google.com> |
when database is opened, set journal_mode to TRAUNCATE
this journal_mode is more efficnent than the default journal_mode (DELETE)
Change-Id: I8879d3fe8dda410f4674ead9270aa7ecdaf91b5e
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| e407a608b0e2c7aad5cd6321426ec85d35f3bafa |
|
04-Jun-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
resolved conflicts for merge of 7d6362de to master
Change-Id: Ic26dd6d617f0edba549c992256511613df00caa6
|
| 2134369e803e944af84e73dcaf9356609a5481c6 |
|
04-Jun-2010 |
Vasu Nori <vnori@google.com> |
set some members to final, set database errorhandler to default if null.
Change-Id: I1c2d8181e7fe60c869178a43dcc00519dd0072c7
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| cfda9f3a4756c71b3aadd1387419cb3b513dd400 |
|
03-Jun-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Sprinkle new BlockGuard around SQLiteDatabase.
SQLite is JNI to native code and doesn't go via IFileSystem, so it
needs custom sprinkling, at least for now.
Change-Id: Ic7fded1b64a4f483dfc17b3a7b136c803df1e111
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.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/SQLiteDatabase.java
|
| ccd954480c32e9f35357b66023ae912e7f3fa76b |
|
29-May-2010 |
Vasu Nori <vnori@google.com> |
cleanup some small but ugly things. all minor things.
Change-Id: I6a3ea9ad563ea895e7f3c37647bdadd2cfa8fc29
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| a8c24904ebb301d1a95f9c780aabbe4ebe7026c8 |
|
01-Jun-2010 |
Vasu Nori <vnori@google.com> |
set sqlite pagesize to the size, in bytes, of a block on "/data"
Change-Id: I40b2bdac348a611eb9fe12ea05b6bd9a87f2310a
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| fea6f6dcb70e3fa7f60cab970ed444b5e5e2a3fa |
|
22-May-2010 |
Vasu Nori <vnori@google.com> |
sqlite crashes when closing the database
A change was made in the last CL to ask sqlite for all unfinalized statements
and then finalizing them before closing the database.
But this crashes sqlite! because sqlite's FTS3
module keeps some prepared statements around and they should not
be finalized before closing the database.
(when sqlite is asked for all unfianlized statements, it also returns
the FTS3's reserved prepared statements which should not be
finalized!!)
Change-Id: I141ab4563985b8cd1305a1228c4cb01bc7281bcb
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 6f37f83a4802a0d411395f3abc5f24a2cfec025d |
|
19-May-2010 |
Vasu Nori <vnori@google.com> |
close() on anything other than database shouldn't acquire db lock.
bug:2683001
implmentation details:
1.close() on any sql statement is should simply queued up for finalization
to be performed later. caller doesn't acquire database lock.
2. the only effect of NOT close immediately is non-release of some memory.
3. all such queued-up-finalizations are performed whenever there is
another execute() of some sql statement on that database from ANY
thread in the process.
4. database close() automatically releases all unfinalized statements
before closing the database.
Change-Id: If4c9c7fde6b8945a41abc6c8b992aa8c69854512
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 6df9720b8d3fbd2c4f0095ceda488b0fe1100c52 |
|
13-May-2010 |
The Android Open Source Project <initial-contribution@android.com> |
am fd5b040a: am 485b800e: am 1a3b3d48: merge from open-source master
|
| 1a3b3d48413d9134738c9b457292fb2b71a5dfe4 |
|
13-May-2010 |
The Android Open Source Project <initial-contribution@android.com> |
merge from open-source master
Change-Id: I51b4eccfde8e74c69ab8e0c051bb8ea718ee7101
|
| f3ca9a5c7e87319c934b5815566054d2e5c2085f |
|
13-May-2010 |
Jeff Hamilton <jham@android.com> |
Add some documentation about the thread safety of Cursor and some of the SQLite* classes.
Change-Id: Icae51052d1c942d7d60bb958d3703411da001079
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 9463f297ef51bd056626d0fb0708c83509f7ebd9 |
|
30-Apr-2010 |
Vasu Nori <vnori@google.com> |
sometimes database lock is not held before compiling a statement
indirectly uncovered by bug:2631971
Change-Id: I71059b6b62bc21612fc98689aefd4534884c8e7c
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| ca3a7b9bc55ef232c282108cf9d65cb81d008d68 |
|
29-Apr-2010 |
Vasu Nori <vnori@google.com> |
am 43f2c35b: am 91a62f3d: am a07c4cbe: Merge "bug:2622719 move \'forcing of cursor execution\' to ContentProvider" into froyo
|
| 020e5345795a157d7829ebbe4d7864595dafc576 |
|
28-Apr-2010 |
Vasu Nori <vnori@google.com> |
bug:2622719 move 'forcing of cursor execution' to ContentProvider
revert part of the CL: Ia561135e974a44ad3e3774ecb23c6a3d0fc38176
and add it to ContentProvider.query() to force query execution
in worker thread, instead of having the main thread incur the cost
of query execution and potentially get ANR
Change-Id: I0ea8a170bd954a421f4ad825f8090319a83a5b2b
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 9504c70f8862f5ffc55b07bc374e0b18b78a2dc6 |
|
23-Apr-2010 |
Vasu Nori <vnori@google.com> |
fix a bug introduced when prepared-statement cache was made LRU-based
1. when an entry is pushed out of cache, it should be released if it is not
in use by any thread. This didn't have to be done when cache was NOT LRU
because the object either got into the cache while the caller had a reference
to it or it didn't. if it didn't get into cache (because cache is full),
the caller's close() released the object. But in LRU cache, an object
could get pushed out of cache due to LRU policy and if it is NOT in use
by any thread at the time it was pushed out of cache, then it
got GC'ed - which caused warnings to be pronted in the log.
2. also delete some unused methods in SQLiteDatabase.
Change-Id: I7831952647d3a057342bcc8ac186a6a26eb58f33
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.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/SQLiteDatabase.java
|
| 119c106f8d0dc884b239c5d88b0fd43002b3e32d |
|
15-Apr-2010 |
Vasu Nori <vnori@google.com> |
am 9d3b3e13: am bad5f620: am 0bbcdc6c: Merge "verify database state before calling sqlite. Bug:2593970" into froyo
|
| 062fc7ce369758d5a26f83f12b50b11cd88e5def |
|
01-Apr-2010 |
Vasu Nori <vnori@google.com> |
allow apps to specify actions to take on database corruption error
let the user specify an interface impl class to specify the actions
to take when db corruption is detected.
this class is specified when the database is opened/created.
Change-Id: I84eb57208c8fedfa7235805b0ec58165efdc1560
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| c8e1f23891cff31a9da2bab412631ff770a92f56 |
|
14-Apr-2010 |
Vasu Nori <vnori@google.com> |
verify database state before calling sqlite. Bug:2593970
Change-Id: Id68365abccbdca572ad13c2b51162d53993ff540
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 90a36726b7553a1e7efd2f4ecbe01d7e1b3e7a67 |
|
12-Apr-2010 |
Vasu Nori <vnori@google.com> |
let apps set statement-cache size.
1. we should let apps set their statement-cache size. right n ow it is 250
is the statement-cache size for all apps and that is wasting
a lot of memory. each prepared statement is averaging about 1k-5K,
depending upon the complexity of sql and schema.
mnake default 25 and let apps increase the size, if they need to.
2. in "adb bugreport" info, print stats on the statement-cache hits/missies
and size (in number of statement cached). this will help us understand
how statement-cache is being used
Change-Id: Ic53a2842ef75823757492778158fcb8d5b4a28bb
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 8f29c12d6ebfa3ed36e81573448fcbc49a98f514 |
|
24-Mar-2010 |
Dmitri Plotnikov <dplotnikov@google.com> |
Forcing query execution in SQLiteDatabase.query
The issue is that our code often "executes" a query
on a background thread but iterates over the cursor
on the UI thread. Since we actually do the fetch
on moveToFirst or moveToNext, the query is in reality
often run on the UI thread and causes an ANR.
Change-Id: Ia561135e974a44ad3e3774ecb23c6a3d0fc38176
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 722802e76b8805da523a612ad3482450fd327db0 |
|
24-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Log database lock contention as well (as seperate pseudo-queries).
This also makes the 500ms logging threshold (over which is always
logged, and under which is sub-sampled) configurable via a
SystemProperty, which is mostly useful for interactive debugging when
lock contention is suspected, but could also be useful in the future
as a quick way to adjust this threshold for dogfooders, without code
changes.
Change-Id: I769069d8d870331d89a4aa3239ba50db806fe4d4
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| f3cf8a4da8ef28e62586cc07edce99879e2c3a56 |
|
23-Mar-2010 |
Vasu Nori <vnori@google.com> |
when corruption occurs, log a warning before closing db
and database.close() should NOT set mPath to null.
a few other minor changes included in this CL
1. if it is memory database, no need to delete any file
2. if 2 threads are sharing the same connection, and if corruption occurs
on it, one thread closes the db and deletes db - while the other
thread is still using it. this can cause SQLITE_MISUSE error.
to prevent this, every method in SQLiteDatabse should make sure
db is open before exec'ing sql statements. bug:2531172
Change-Id: I4cb5ab8539f46d7f8b26c3f830d799adf46444b6
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| f6373e9513002f55bbe00180a5eb9f1051d53547 |
|
16-Mar-2010 |
Vasu Nori <vnori@google.com> |
close() database should close the db no matter what the ref count says
bug:2455416
Change-Id: Ia995c952c6941fbaa016c5b251e4980fa5328fbb
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| c3849200fa60b22ea583ba2a6f902d6a632a5e7e |
|
09-Mar-2010 |
Vasu Nori <vnori@google.com> |
add more debug info to SQL section in bugreport
after this CL, adb bugreport will the following info (under SQL section
of each app's meminfo dump)
SQL
heap: 344 memoryUsed: 344
pageCacheOverflo: 67 largestMemAlloc: 50
DATABASES
Pagesize Dbsize Lookaside Dbname
1024 7 24 googlesettings.db
1024 26 110 talk.db
1024 11 0 (attached) transient_talk_db
1024 11 32 subscribedfeeds.db
1024 20 27 gservices.db
Change-Id: Iabd13be9793d9794137c60a045b84fa632f13498
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 49d02acec84cc0382286fa233135bb5c74d5bdbf |
|
06-Mar-2010 |
Vasu Nori <vnori@google.com> |
caching bug in SQLiteDatabase causes invalid finalizer warnings
a bug in maintaining the cache caused these warnings. when the cache
is full, caching code in SQLiteDatabase dropped an entry from the cache
to accommodate the new one. and if the just-dropped one is not in use
that object got GC'ed and caused a finalizer warning. Calendar is one app
that didn't use ? for bindargs (sometimes) and noticed this bug in that app
Fix is to not add the new enry to cache if the cache is already full.
that will cause the app's close() to release the entry.
another common case where this finalizer warning occurs is when unittests run.
if the test does not close the database in tearDown(), it will cause
database object and the compiled sql statement cache within the database
obj get GC'ed which cause finalizer warnings.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| fb3803a360531020ed605247cb26a476f1c379bd |
|
04-Mar-2010 |
Vasu Nori <vnori@google.com> |
a dbobject is closed twice and that causes incorrect warnings
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 08b448ea39e9fabfc5212ae6f7226eba4385d189 |
|
03-Mar-2010 |
Vasu Nori <vnori@google.com> |
in finalizer warnings, use a better exception - NOT Exception()
finalizer warnings should use a more descriptive exception instead of
Exception() so it is clearer to the developers as to why this
warning is output.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| d606b4bf2c1a2308b40785860853cfb95a77bf58 |
|
24-Feb-2010 |
Vasu Nori <vnori@google.com> |
in finalize() methods, log warnings if db lock is going to be held.
this is to track bug:2463988 and bug:2457342
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 25880968cbde25c9edb162c0d70d45dc75239456 |
|
23-Feb-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Reduce SQLiteDatabase and ContentResolver EventLog logging thresholds.
Turns out the database is used a ton, and not particularly quickly, so
these were spamming the logs at their prior 100ms thresholds. Setting
it to 500ms now. (still sub-sampled, so should be ~5x less spammy...)
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| d833023307494d5bfe3fdc1ce79761fb8c9f49a6 |
|
19-Feb-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Don't let email addresses in database names get into the EventLog.
Because some apps make SQLite database names containing email
addresses, we take care not to log those email addresses in the
EventLog, so other apps with READ_LOGS access can't read them.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| b28c7972bd3e5e34138e2fd7a2e1433d65205bdf |
|
12-Feb-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Log previous SQL statement also when logging "COMMIT;" operations.
Previously, as somewhat expected, the top SQL statements showing up in
the SQL analysis dashboards from developer phones was just "COMMIT;"
statements, which is pretty uselessly ambiguous.
Now the logs for commit operations look like:
I/db_operation( 1249): [/data/data/com.google.android.gsf/databases/subscribedfeeds.db,COMMIT;DELETE FROM _deleted_feeds WHERE _sync_account=? AND _syn,461,com.google.process.gapps,100]
I/db_operation( 1290): [/data/data/com.android.providers.contacts/databases/contacts2.db,COMMIT;SELECT account_name, account_type FROM _sync_state,126,android.process.acore,100]
I/db_operation( 1249): [/data/data/com.google.android.gsf/databases/talk.db,COMMIT;INSERT OR REPLACE INTO providerSettings(value, name) VAL,252,com.google.process.gapps,100]
I/db_operation( 1377): [/data/data/com.android.providers.calendar/databases/calendar.db,COMMIT;SELECT localTimezone, minInstance, maxInstance FROM Calen,948,,100]
I/db_operation( 1377): [/data/data/com.android.providers.calendar/databases/calendar.db,COMMIT;SELECT begin-(minutes*60000) AS myAlarmTime, Instances.ev,82,,83]
It doesn't totally pin-point the offending code, but it should get us
most of the way there. We may enhance this logging again in the
future.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| d72f718c9cc4bd5e4701f4c5cdab51b4d8cf6435 |
|
12-Feb-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Measure walltime in ContentResolver and SQLiteDatabase operations logging.
Previously, SQLiteDatabase was using Debug.threadCpuTimeNanos(), which
doesn't include I/O time (user-perceived latency), and ContentResolver
was using System.currentTimeMillis(), which didn't account for deep
sleeps.
Now both are consistently using SystemClock.uptimeMillis().
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 82f82be4b3f97cd8a1fd298d8389f5dc54fea01d |
|
09-Feb-2010 |
Vasu Nori <vnori@google.com> |
change wording in warning msg printed when compiled-sql cache is full
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 8d45e4e4c6244cc3a508da3b56fec8cfd4cadd1d |
|
06-Feb-2010 |
Vasu Nori <vnori@google.com> |
changes after review by API council
please refer to http://b/issue?id=2420299
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 3ef94e25b4c896ecaa85aa2c12b8863ecdf98df0 |
|
05-Feb-2010 |
Vasu Nori <vnori@google.com> |
use sqlite 3.6.22 to print and profile the sql statetements
instead of rolling our own trace/profile code in java, lets use
sqlite 3.6.22 features. turns out sqlite does a good job of
printing the sql statements - including the ones from the triggers.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| adf1c58fa91c3051697a14e3c7cc8a47e5d1dd83 |
|
06-Feb-2010 |
Vasu Nori <vnori@google.com> |
fix a warning message that is confusing people.
warning message printed when the compiled-sql statament cache is emptied out is
not making sense to people. hope this version is better.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 4dd4ab4cc322e82401f380aeb877daa4a20d7069 |
|
30-Jan-2010 |
Vasu Nori <vnori@google.com> |
add instrumentation to log the sql statement + bindargs + databasename
capture the sql statement along with the bindargs passed in. this will help
one to see the sql statements being executed and hopefully will help
debug incorrect-sql bugs.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 6eb7c45a8fdb774c4094b5012c8496f2a009c032 |
|
27-Jan-2010 |
Vasu Nori <vnori@google.com> |
make SqliteDatabase ConflictAlgorithm and associated methods public.
SQLiteDatabase.java has ConflictAlgorithm which allows callers to specify
actions to take when insert or update causes constraint violations.
These actions are documented at http://www.sqlite.org/lang_conflict.html.
why make these public? usecase is the following:
Gmail has a table with a column "_id" being the integer primary key and
they let sqlite assign key values to the column.
but there is another UNIQUE key column (message_id) in the table.
so an insert could fail due to constraint violation on the message_id column
(i.e., not on the primary key). and when that happens, they would like to
get the value of _id that caused constraint violation.
currently hidden method insertOnConflict() already provides the above
functionality. that means exposing ConflictAlgorithm also.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 994bc22f1e89efae7739c50c41fcf23c6e4847a6 |
|
21-Jan-2010 |
Vasu Nori <vnori@google.com> |
caching PRAGMA sql statements caused cts-tests failures.
thats a strange-bug..caching PRAGMA sql statements caused sqlite to return
incorrect results.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| e9d9210205b280b4ea0402f78d7dd717068af650 |
|
21-Jan-2010 |
Vasu Nori <vnori@google.com> |
reduce logging noise from cache-full conditions.
when the compiled-sql cache is full, print the warning only a few times and
after that, if the condition persists, clear the cache.
don't flood the cache with the same warning million times.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| bee5b9d7cb9071b617810b8018e69b6815478e46 |
|
15-Jan-2010 |
Vasu Nori <vnori@google.com> |
Change Log.wtf() call to Log.w()
messages from Log.wtf() sound pretty bad and engineers seem to think
something terrible has gone wrong.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| e495d1f74af13aec8d5d825e93e4cfe1e4fe7468 |
|
07-Jan-2010 |
Vasu Nori <vnori@google.com> |
fix a bug in compiled-sql caching & hide public api setMaxSqlCacheSize
this is a clone of https://android-git.corp.google.com/g/#change,35174.
if the cache is full to its capacity and if a new statement is to be cached,
one of the entries in the cache is thrown out to make room for the new one.
but the one that is thrown out doesn't get deallocated by SQLiteProgram
because it doesn't know that it should.
fixed this by having SQLiteProgram finalize its sql statement in
releaseReference*() methods, if the statement is not in cache.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 380ae0a6d491e04c2ddc86102ef7b753d402a35f |
|
11-Jan-2010 |
Vasu Nori <vnori@google.com> |
am 9c74295f: am a1759cea: Merge "add eventlog message whenever sqlite reports db corruption error" into eclair
Merge commit '9c74295fb16da0469304a7c04c471915e28d09bd'
* commit '9c74295fb16da0469304a7c04c471915e28d09bd':
add eventlog message whenever sqlite reports db corruption error
|
| dd1b39be1e077d19911e8dc7bf00db0e31b63287 |
|
08-Jan-2010 |
Vasu Nori <vnori@google.com> |
add eventlog message whenever sqlite reports db corruption error
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| fa1fae1355b240856bcacf51d54e459c81e0c78c |
|
07-Dec-2009 |
Vasu Nori <vnori@google.com> |
Revert "dealloc compiled-sql statements before deref'ing them from SQLiteDatabase obj."
This reverts commit 6d1ec0d81cd8ecdd390b31e724bac554bb955a94.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 6d1ec0d81cd8ecdd390b31e724bac554bb955a94 |
|
02-Dec-2009 |
Vasu Nori <vnori@google.com> |
dealloc compiled-sql statements before deref'ing them from SQLiteDatabase obj.
dealloc compiled-sql statements before removing references of SQLiteClosable objects from SQLiteDatabase obj. otherwise, code will attempt to close database before deallocing the compiled-sql statements and that causes sqlite exceptions.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 799f721fcbff7a5ef62141786a642290f275903b |
|
25-Nov-2009 |
Dan Egnor <egnor@google.com> |
Fix a bug in the Settings contract class (introduced in an ... iffy ... fix
to a race condition) that breaks the caching of non-existent Settings/Secure/
Gservices values (causing lots of unnecessary database queries).
Fix a dumb thinko (reversed condition) in the SQLiteDatabase logging.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 12311959c6ec6898e3b40d4e8958b29ec0b72da9 |
|
23-Nov-2009 |
Dan Egnor <egnor@google.com> |
Expand db_operation logging to prepare for widespread sample collection:
- always enable the log, but subsample for queries faster than 100ms
- add information about whether it's blocking a main thread
- log the entire sql (have not yet added quoted-string-stripping)
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 5a03f36ef845f73eb4473193dbb0f93dd12a51af |
|
21-Oct-2009 |
Vasu Nori <vnori@google.com> |
maintain cache of statementids returned by sqlite upon compiling a sql stmnt
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 082c2af6859dff103e781b372dfde927cc0f869f |
|
29-Sep-2009 |
Jeff Hamilton <jham@android.com> |
EventLog when a database file is deleted due to corruption.
Change-Id: Icbd747425e97e022b91fbaf64579982d802524bf
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| a722d5b1bd878e63c9d567d457554feeef5f1fee |
|
29-Sep-2009 |
Jeff Hamilton <jham@android.com> |
EventLog when a database file is deleted due to corruption.
Change-Id: Icbd747425e97e022b91fbaf64579982d802524bf
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 90142c959e6de38eae1563cd8b3d2d448393e15f |
|
15-Sep-2009 |
Dmitri Plotnikov <dplotnikov@google.com> |
Adding a system property to log slow queries
Change-Id: I4d139e222319f56169924e14aa967f07b233c00e
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| b43b58d3494426eda6117101635de25bb43efc20 |
|
10-Sep-2009 |
Dmitri Plotnikov <dplotnikov@google.com> |
Increasing uninterrupted sleep quantum in SQLiteDatabase to increase transaction size.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| c4516a7b62de525e3d6d5e76851bdfaf12c11f05 |
|
03-Sep-2009 |
Fred Quintana <fredq@google.com> |
add a transaction monitor
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 600bdd82f58c7338e68ce2c8f04b17db4cf4f910 |
|
01-Sep-2009 |
Dmitri Plotnikov <dplotnikov@google.com> |
Breaking sleep after yield into small quanta.
Rationale: there is no reason to sleep for 4 seconds between
transactions if there is no one using the database. This long
sleep only makes sense if two threads are actively using
the database yielding to each other every several seconds.
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 5c7aede8d69f4f0ad617d39decd4453b029ba6af |
|
28-Aug-2009 |
Fred Quintana <fredq@google.com> |
allow delaying after yielding
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 4a51c20ce607c74914f90fd897f04080121ac13b |
|
22-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
I am getting tired of the java doc warnings, so fix them.
Change-Id: I2205eebae419eaf4a0992c9f5b7cd807eb843fe1
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 7f4c2ea378b98162fd7d3740293cfb2dfecbfc90 |
|
22-Jul-2009 |
Bjorn Bringert <bringert@android.com> |
Fix SQL generated by updateWithOnConflict()
Before, SQLiteDatabase.updateWithOnConflict() method generated
syntactically invalid SQL if the ConflictAlgorithm was non-null.
For example, it would generate
"UPDATE OR REPLACEshortcuts SET ...",
when it should be "UPDATE OR REPLACE shortcuts SET ...".
Fixes http://b/issue?id=1995470
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| f8a7ceaef2e7d5cd530c9426bde91b6fa9a40b75 |
|
11-Apr-2009 |
Andy Stadler <> |
AI 145778: Manual merge changes 145382-145384 from cupcake.
Automated import of CL 145778
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.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/SQLiteDatabase.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/SQLiteDatabase.java
|
| 076357b8567458d4b6dfdcf839ef751634cd2bfb |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@132589
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|
| 3dec7d563a2f3e1eb967ce2054a00b6620e3558c |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@137055
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.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/SQLiteDatabase.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/SQLiteDatabase.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/database/sqlite/SQLiteDatabase.java
|