Lines Matching full:database
97 <li> <a href="#Database_formats">Database formats</a>
180 to test the database upgrades from 1.0 database scheme to a new scheme, any work done in Cupcake will
181 have to work within the existing 1.0 database scheme.
247 The <code>URI</code> column is visible to the initiating application, which is a mild security risk. It should be hidden, but the OTA update mechanism relies on it to check duplicate downloads and to display the download that's currently ongoing in the settings app. If another string column was exposed to the initiating applications, the OTA update mechanism could use that one, and <code>URI</code> could then be hidden. For Cupcake, without changing the database schema, the <code>ENTITY</code> column could be re-used as it's currently unused.
260 If the <code>URI</code> column gets hidden, it could be used to store the intermediate URIs. After 1.0 the only available integer columns were <code>METHOD</code> and <code>CONTROL</code>. <code>CONTROL</code> was re-exposed to applications and can't be used. <code>METHOD</code> is slated to be re-used for 503 retry-after delays. It could be split into two halves, one for retry-after and one for the redirect count. It would make more sense to count the redirect loop with <code>FAILED_CONNECTIONS</code>, but since there's already quite some code using it it'd take a bit more effort. Ideally handling of redirects would be delayed until a future release, with a cleanup of the database schema (going along with the cleanup of the handling of filenames).
262 Because of the pattern used to read/write <code>DownloadInfo</code> and <code>DownloadProvider</code>, it's impractical to store multiple small integers into a large one. Therefore, since there are no integer columns left in the database, redirects will have to wait beyond Cupcake.
744 As a first approach, the provider is essentially a canonical provider backed by a SQLite3 database. The biggest difference between the download provider and a "plain" provider is that the download provider aggressively validates its inputs, for security reasons.
786 <h3><a name="Database_formats"> </a> Database formats </h3>
1051 <li> The database could be somewhat checked when it's opened.
1053 <li> <em>[DownloadProvider.java]</em> When upgrading the database, the numbering of ids should restart where it left off.
1057 <li> <em>[DownloadProvider.java]</em> Explicitly populate all database
1063 <li> <em>[DownloadService.java]</em> Trim the database in the provider, not in the service. Notify application when trimming. Investigate why the row count seems off by one. Enforce on an ongoing basis.
1067 <li> <em>[DownloadThread.java]</em> Deal with mistmatched file data sizes (between database and filesystem) when resuming a download, or with missing files that should be here.
1077 <li> Deal with situations where /data is full as it prevents the database from growing (DoS) .
1087 <li> Should keep a bit of "emergency" database storage to initiate the download of an OTA update, in a file that is pre-allocated whenever possible (how to know it's an OTA update?).
1122 <li> Document the database columns that are most likely to stay unchanged throughout versions, to increase the chance being able to perform downgrades.
1150 <li> Optimize database queries: use projections to reduce number of columns and get constant column numbers.
1158 <li> Could use fewer alarms - currently setting new alarm each time database updated .
1160 <li> Obsolete columns should be removed from the database .
1166 <li> There's potentially a race condition around read-modify-write cycles in the database, between the Service's updateFromProvider thread and the worker threads (and possibly more). Those should be synchronized appropriately, and the provider should be hardened to prevent asynchronous changes to sensitive data (or to synchronize when there's no other way, though I'd rather avoid that) .
