incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shazron Abdullah (JIRA)" <>
Subject [jira] [Commented] (CB-684) WebKit database restore on iOS5.1 corrupts large databases
Date Sat, 12 May 2012 00:47:48 GMT


Shazron Abdullah commented on CB-684:

How would you want this to work (re: the "hook")? Actually I found a way to enable background

I'm not sure if it will even provide enough time in your case, but I can give it a try.
Obviously it is iOS 4 only (it uses blocks), but I suppose you don't care for iOS 3.x (currently
Cordova doesn't work with iOS 3 anyway).

I'll attempt this for 1.8.0, and it should work for the general case. I don't know if it will
work for you, since the amount of time allotted to an app is controlled by iOS, but most reports
say it is 10 mins.

> WebKit database restore on iOS5.1 corrupts large databases
> ----------------------------------------------------------
>                 Key: CB-684
>                 URL:
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: iOS
>    Affects Versions: 1.6.1
>         Environment: iOS5.1
>            Reporter: Neil Harding
>            Assignee: Shazron Abdullah
>            Priority: Critical
>              Labels: database, ios, sqlite, webkit
> The backup and restore process for WebKit databases on iOS5.1 to copy databases from
the /library/caches folder to /documents/backup is corrupting large databases. 
> I have a 1Gb sqllite databases, this is is because there will be a lot of data in the
app and to get around the 5mb quota limit for Websql databases on iOS a large pre populated
.db file is copied over to /library/caches on app start up in didFinishLaunchingWithOptions
if it doesn't already exist. This 'reserves' the footprint of the database as sqlite doesn't
unallocated space when deleting rows, the data is cleared out and the app can start off without
any quota errors.   
> When the app terminates and the backup process runs to copy the .db file to /documents/backup
it doesn't complete the process successfully (possibly killed by iOS before the file is fully
written?) and the resulting file .db is much smaller (~200mb) and corrupt.
> When the app runs next time the .db is copied from /documents/backup to /library/caches
ok, but the damage is already done.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message