| 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/SQLiteProgram.java
|
| b2679481b57d87945df02983f95ff8e6c9ba5928 |
|
12-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix potential NPE in SQLiteProgram.
Bug: 6122537
Change-Id: I76a12f58f08b708065dfdd11c78f54701d90873b
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.java
|
| d5064be3b5922ee6522a33f8b729ffee2e3d7b4b |
|
14-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Make SQLiteQuery and SQLiteProgram final.
We can do this because the classes already cannot be subclassed
by applications due to the fact they only have package private
constructors.
One very nice consequence of this observation is that we can hide or
delete several @deprecated protected members which are effectively
inaccessible because applications cannot create subclasses!
Change-Id: I2d3a0d2ad72b9289ebcdf907e4e4e6caf27f9076
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.java
|
| 4e874edf69ce9900eb847629dc4d3616972a3468 |
|
16-Sep-2010 |
Vasu Nori <vnori@google.com> |
don't compile statement for certain SQL statements
SQL statements such as Create table, Pragma, Begin, Commit, Rollback
etc don't need a compiled statement.
Change-Id: I55f5e4e6cbb41cbe83e592e25ba852fe23e2b39f
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.java
|
| 196663234ab1b67fdd88060701e8211f67fd7854 |
|
10-Sep-2010 |
Vasu Nori <vnori@google.com> |
remove unnecessary synchronization object from SQLiteClosable.
and a couple of other minor SMP fixes
Change-Id: I62bb4dd2fe43fc41074454a25bd84ad1fb4d004d
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.java
|
| 441fcf13f3bbfd2fb9de273d3d552aad2a7ae9af |
|
08-Sep-2010 |
Vasu Nori <vnori@google.com> |
remove some useless code and add some code to aid in debugging
Change-Id: Ie532848b82dde57cc7a7017661679ece06ca606e
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.java
|
| e25539fdfdf884eee55107efbcc893f44e82e00e |
|
09-Jul-2010 |
Vasu Nori <vnori@google.com> |
reduce locking when using SQLiteStatement
Do compiling of sql, binding of args and execution of the SQL
statement within one single database lock period.
This reduces the number of times the database lock
needs to be acquired during the course of compilation, binding
and execution of a SQLiteStatement.
Change-Id: I22b090ec9e10fc0aa2532a93bafe610af2546b58
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.java
|
| b2d2ddc5ac67be16b85075c1f7e9ac8b5ae50ce2 |
|
08-Jul-2010 |
Vasu Nori <vnori@google.com> |
reduce java locking on SQLiteDatabase if sql is already compiled
Change-Id: I6c2c593ba69aad201cedf097384d0b5d835c0839
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.java
|
| 59d60420ba9246eee152852b6a597a0aba7f704d |
|
04-Jul-2010 |
Vasu Nori <vnori@google.com> |
deprecate method returning prepared sql statement id
this method causes sql statement in a SQLiteProgram object to be never
re-compiled. thats not desirable, is it?
there should be no need for this method.
Change-Id: I207fad6415c1e2ef4097ee65a3ff347b5435b994
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.java
|
| 0dbb9cee58d35d30f205dc844a82e960149fa86b |
|
16-Apr-2010 |
Vasu Nori <vnori@google.com> |
accept close() on database objects even if the database is closed
bug:2602878
Change-Id: I3075f801ef35d72792ff3daaa1e887e53b58f5f8
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.java
|
| 3695709457c66354261502b8bf23d59604a59ce4 |
|
11-Mar-2010 |
Vasu Nori <vnori@google.com> |
debug-flag covered log messages to help people debug finalizer stuff
should help developers figure out why finalizer warnings are coming out
of their app.
Change-Id: I50a4ba96c84c6b3cf4445331e1fb55320d8783e1
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.java
|
| 8648e37f82f15f0e13acc14e4cbf4df377cf8063 |
|
09-Mar-2010 |
Vasu Nori <vnori@google.com> |
add REPLACE to the list of cached sql stmnts
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.java
|
| 14b60e747cdf16b79bb755b42dd766348c4f1880 |
|
01-Mar-2010 |
Vasu Nori <vnori@google.com> |
add warning in finalizer. deprecate protected members.
finalizer shoudl not be called ever. add a warning to say that.
adeprecate a few members in SQLiteProgram.java. they should not
have had protected access level. shoudl be package.
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.java
|
| 1d7265800d91c79346f03d635d5b417b3d4a7e31 |
|
24-Feb-2010 |
Vasu Nori <vnori@google.com> |
yet another race condition fix to address bug:2456970
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.java
|
| ec37e42fb260b867b19eb01606867a85ba2e5187 |
|
22-Feb-2010 |
Vasu Nori <vnori@google.com> |
fix race condition introduced by CL https://android-git.corp.google.com/g/40395
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.java
|
| e8de28415b4362824a52c180adf10dd882d12eaf |
|
18-Feb-2010 |
Vasu Nori <vnori@google.com> |
bug fix for 2419869. also included 2 unittests.
bug fix for 2419869 is the following
1. only one object can use the prepared statement object
(SQLiteCompiledSql in SQLIteProgram)
2. if two objects are requesting to use it, then create a new prepared
statement object for exclusive use by the newcomer and let it be
be finalized by the newcomer.
3. add mInUse flag to SQLiteCompiledSql - to be set when SQLiteProgram
requests it and to be released when that SQLiteProgram is done with it
a couple more changes included are
1. unitests to simulate bug # 2419869 (and the fix's repair to it)
2. better logging in SQLiteCloseable when it prints log messages
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.java
|
| b1dd3235a901e4c3c51ed910e29e0afa15fddb19 |
|
01-Dec-2009 |
Vasu Nori <vnori@google.com> |
fix NPE. don't release an already released compiledSql obj
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.java
|
| 4df2423a947bcd3f024cc3d3a1a315a8dc428598 |
|
05-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@136594
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.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/SQLiteProgram.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/database/sqlite/SQLiteProgram.java
|