Develop Reference

How do SQLite transactions on Android work?

My understanding of SQLite transactions on Android is based largely on this article. In its gist it suggests that
if you do not wrap calls to SQLite in an explicit transaction it will
create an implicit transaction for you. A consequence of these
implicit transactions is a loss of speed
.
That observation is correct - I started using transactions to fix just that issue:speed. In my own Android app I use a number of rather complex SQLite tables to store JSON data which I manipulate via the SQLite JSON1 extension - I use SQLCipher which has JSON1 built in.
At any given time I have to manipulate - insert, update or delete - rows in several tables. Given the complexity of the JSON I do this with the help of temporary tables I create for each table manipulation. The start of the manipulation begins with SQL along the lines of
DROP TABLE IF EXISTS h1;
CREATE TEMP TABLE h1(v1 TEXT,v2 TEXT,v3 TEXT,v4 TEXT,v5 TEXT);
Some tables require just one table - which I usually call h1 - others need two in which case I call them h1 and h2.
The entire sequence of operations in any single set of manipulations takes the form
begin transaction
manipulate Table 1 which
which creates its own temp tables, h1[h2],
then extracts relevant existing JSON from Table 1 into the temps
manipulates h1[h2]
performs inserts, updates, deletes in Table 1
on to the next table, Table 2 where the same sequence is repeated
continue with a variable list of such tables - never more than 5
end transaction
My questions
does this sound like an efficient way to do things or would it be better to wrap each individual table operation in its own transaction?
it is not clear to me what happens to my DROP TABLE/CREATE TEMP TABLE calls. If I end up with h1[h2] temp tables that are pre-populated with data from manipulating Table(n - 1) when working with Table(n) then the updates on Table(n) will go totally wrong. I am assuming that the DROP TABLE bit I have is taking care of this issue. Am I right in assuming this?
I have to admit to not being an expert with SQL, even less so with SQLite and quite a newbie when it comes to using transactions. The SQLite JSON extension is very powerful but introduces a whole new level of complexity when manipulating data.

The main reason to use transactions is to reduce the overheads of writing to the disk.
So if you don't wrap multiple changes (inserts, deletes and updates) in a transaction then each will result in the database being written to disk and the overheads involved.
If you wrap them in a transaction and the in-memory version will be written only when the transaction is completed (note that if using the SQLiteDatabase beginTransaction/endTransaction methods, that you should, as part of ending the transaction use the setTransactionSuccessful method and then use the endTransaction method).
That is, the SQLiteDatabase method are is different to doing this via pure SQL when you'd begin the transaction and then end/commit it/them (i.e. the SQLiteDatabase methods would otherwise automatically rollback the transactions).
Saying that the statement :-
if you do not wrap calls to SQLite in an explicit transaction it will
create an implicit transaction for you. A consequence of these
implicit transactions is a loss of speed
basically reiterates :-
Any command that changes the database (basically, any SQL command
other than SELECT) will automatically start a transaction if one is
not already in effect. Automatically started transactions are
committed when the last query finishes.
SQL As Understood By SQLite - BEGIN TRANSACTION i.e. it's not Android specific.
does this sound like an efficient way to do things or would it be
better to wrap each individual table operation in its own transaction?
Doing all the operations in a single transaction will be more efficient as there is just the single write to disk operation.
it is not clear to me what happens to my DROP TABLE/CREATE TEMP TABLE
calls. If I end up with h1[h2] temp tables that are pre-populated with
data from manipulating Table(n - 1) when working with Table(n) then
the updates on Table(n) will go totally wrong. I am assuming that the
DROP TABLE bit I have is taking care of this issue. Am I right in
assuming this?
Dropping the tables will ensure data integrity (i.e. you should, by the sound of it, do this), you could also use :-
CREATE TEMP TABLE IF NOT EXISTS h1(v1 TEXT,v2 TEXT,v3 TEXT,v4 TEXT,v5 TEXT);
DELETE FROM h1;

Android: Failing to update row using SQL Extension function or builtin

I'm having a lot of trouble with SQLiteDatabase command. I have loaded up spatialite and enabled the extension. I want one of my values to be the output of the MakePoint function so I have a content value like this:
values.put("Location", "MakePoint(43.2, 27.345, 4326)");
When this is passed into SQLiteDatabase.Update() it's escapsed so that the resulting string ends up being "UPDATE Targets SET Location='MakePoint(43.2, 27.345, 4326)'" SQLite hates this and throws an exception.
Is there an easy way around this? Right now I'm trying to build up the string manually since I can't use Update.

SQLiteDatabase was not designed for the SpatiaLite extension.
update() supports only simple values, not generic expressions; you cannot use it to insert geographic objects.
The only way to execute your command is to build it manually an run it through execSQL().
You could write your own database wrapper object that understands SpatiaLite data types.

I figured it out. I have to do a "SELECT MakePoint(43.2, 27.345, 4326)" first and then insert that into Location.

inserting to multiple tables with ContentProvider

I'm implementing a PRIVATE ContentProvider which has few tables with relationships (one to many, many to many). In my current implementation all of the tables are accessible by URIs.
how can I simplify the interface so the inner 'through' tables won't have to be accessed by URIs ?
for example, I have a POSTS table, each POST has many TAGS through the TAGGINGS table.
I want to interact only with the POSTS URI and do the 'private' work inside of the ContentProvider.
for query its simple to return a cursor with joined tables, but how do I do this with insert ? is bulkInsert what I should look into ?

It is a limitation of ContentProvider. If you are not exposing your data to other applications you can use your custom database adapter implementation with methods and queries straight hitting your requirements.
bulkInsert() won't help in this situation as it inserts rows only into one table at once. But take a look at ContentProvider.applyBatch() method and ContentProviderOperation, ContentProviderOperation.Builder classes (you may need withValueBackReference() for one-to-many inserting).
These links should help you understand how to use them:
http://www.grokkingandroid.com/better-performance-with-contentprovideroperation/
http://www.grokkingandroid.com/androids-contentprovideroperation-withbackreference-explained/
What are the semantics of withValueBackReference?
But notice, using ContentProviderOperation is much slower than bulkInsert() if you are inserting many rows at once, as it parses Uri (string comparisions) each time the operation is going to be performed. Doing this way you still have to expose Uri for inserting into child table.
If you decide to use applyBatch(), overwrite it in your provider so it performs all operations in one transaction, so you retain consistency in data and speed up database operations:
#Override
public ContentProviderResult[] applyBatch(ArrayList<ContentProviderOperation> operations)
throws OperationApplicationException {
final SQLiteDatabase db = mOpenHelper.getWritableDatabase();
db.beginTransaction();
try {
ContentProviderResult[] results = super.applyBatch(operations);
db.setTransactionSuccessful();
return results;
} finally {
db.endTransaction();
}
}

You are free to insert to multiply tables as long as the values needed are provided.
For example:
ContentValues v = new ContentValues();
v.put("title","post1");
v.put("tag","tag1");
getProvider().insert(POST_URI,v);
In the implementation of insert, you could check if fields (tag) belongs to other table exists.If it does , it means that you should do extra works - insert tag first if it does not exist, set up correct association between the tag and the post just inserted.
You can check the source code of android contacts for the reference.
UPDATE:
To insert multiply tags, one hack-y way is to insert a comma separated string. THis is not elegant but it works.

Just to get this right: You want to have one URI and insert a post and all its tags with one insert call to the ContentProvider? Correct?
The problem is, that you need to have all values in the ContentValues object. There is a reason for normalization in database. Nevertheless it might be doable. For tags this should be easy. Just use one String for all tags. For example "android, ios, bada, wp7" and parse this string in your insert method.
You could also use a naming plus integer convention. And as long as there is a tag1, tag2,... tagX you would read these values from within your ContentProvider's insert method.
Neither is elegant, but would work.
In this case bulkInsert or applyBatch have no place in your code. They come only into play, if you want to use multiple calls to your ContentProvider at once and within one transaction.
But I think the better solution would indeed be to actually use multiple operations as described by biegleux.

Since you are going to be inserting into multiple tables the normal SQLiteDatabase.insert helper functions will not work. But this is completely doable in a performant and nice way.
You need to look at this from the endpoint of the user who is going to be inserting into you ContentProvider, even if it is only yourself. So first define the names or keys for all of you fields. Since you won't be using SQLiteDatabase.insert you don't actually need to name them the same as the database fields. None of the names should be duplicate. If for example you have fields in two different tables overlap perhaps tag in TableA and in TableB you could define the name for those field as TableA.tag and TableB.tag. Or use semantic naming for more descriptive names that don't collide.
Next you need to create your insert queries using SQLiteStatement per this answer. Make sure the names you use in createInsert are the same ones that the callers of the ContentProvider use as keys in the ContentValues.

Is it possible to mock the sqlite3 Cursor in Android when no db or table exists?

I am using a ContentProvider for caching results from a web-service query. It is an HTTP request and the response content is XML. Most of the data is cached, so I simply query the DB, if not found, request from webservice, insert in DB and requery the DB. Thus the response is always a Cursor from SQLiteDatabaseHelper.
I have one result set that is not stored in the DB and since it is 100% transient, but I would like to provide the appearance of it coming from the DB's Cursor. Is there an easy way to do this? For example, if I could project it onto the cursor with a cursor.setValue("string", objectValue) or some other existing implementation.
If not, I will either bypass the DB for this content result, or stuff it into a trivial table that is constantly reused.

Depending on how you use it, it might not be too hard to write your own cursor class. For convenience, derive your class from AbstractCursor class which takes care of a lot of the details for you.
You may also be able to make use of MatrixCursor.

Need help with a really simple database read and write

I'm using a SQL database to store a single float value, and I'm really having trouble getting my brain around everything that needs to be done to make it work. I've been reading the NotePad tutorial Google provides for a few days now and Googling around but it just isn't clicking in my head.
Could anyone explain to me (no code needed) just what exactly I need to have for a simple database, and how to read the value from it into my float variable and how to write the value of the variable back to the table?
Much thanks, I think my brain is starting to seep out my ears.

A SQL database is not a very good way to store a single float value. It's overkill. Instead, I recommend just using Android's SharedPreference class, which provides a simple key-value store.
If you're still going to create a database, what you need is:
The database file.
A SQL schemea for that database file. This describes the tables in the database, as well as the columns. If you're just storing a single float, then you could just create a single table ("data"), with two columns ("key", "value") -- like SharedPreferences, we're just implementing a key-value store of our own (another reason not to do this -- you're reinventing the wheel).
Once that's created, you can just insert a record with some arbitrary key ("myFloat") for lookups later and your chosen value.
So, your initial SQL statement would look something like this:
INSERT INTO data (key, value) VALUES ("myFloat", 3.14);
Later, you'd retrieve it with a SELECT statement:
SELECT key, value FROM data WHERE key="myFloat";
And you can update the value with an UPDATE statement:
UPDATE data SET value=3.14 WHERE key="myFloat";

It is as simple as shown above or just try reading more on SQL queries