11d1e5f60f518e805c5f358f5376b87c08ef69d9 |
|
11-Aug-2014 |
Makoto Onuki <omakoto@google.com> |
Fix getMimeTypeId/getPackageId In the old code we only put ids to the cache in the insert case, but the select case. This means once the process restarts it'd never put anything in the cache. Also added the test for the conflict case. Bug 16574964 Change-Id: I9979b61b6e1a3f04a81bcf2b78a678378f1a009c
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/ContactsDatabaseHelperTest.java
|
ad847316fe64c958b65bc05eb736e704bc56b23f |
|
07-Aug-2014 |
Makoto Onuki <omakoto@google.com> |
Fix "UNIQUE constraint failed: mimetypes.mimetype" With the old code there was a chance of two threads trying to write the same mimetype simultaneously, ending up getting "UNIQUE constraint failed". One possible way to fix it is just to add locks, but doing so *might* cause deadlocks due to implicit locks in SQLiteDatabase. So in this CL, we just retry when we detect a conflict. Unfortunately we can't use a transaction here because this method is called from onCommitTransaction() too. Also refactored the code to unify getPackageId() and getMimeTypeId(). Bug 16574964 Change-Id: I66274dfd080ae808795a4d59d30978b1ca1c06c0
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/ContactsDatabaseHelperTest.java
|
38210445730ee04c351c7cc1b3800cfe23e34325 |
|
27-Jun-2012 |
Makoto Onuki <omakoto@google.com> |
Reorganize import in contacts provider Change-Id: If3afb134ea36bd93859efcd114885526e1592b91
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/ContactsDatabaseHelperTest.java
|
674f943e22077ae399166d5fe8db96dd3d1f7259 |
|
18-Feb-2012 |
Makoto Onuki <omakoto@google.com> |
Remove in-memory account cache Bug 6026073 Change-Id: Ic6057aa2347d1fa4c245ad2f6644ac4d5e8ae3cf
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/ContactsDatabaseHelperTest.java
|
9ba8463dd030e5e26a4f99dfe2a6ad52b2410d73 |
|
11-Jan-2012 |
Makoto Onuki <omakoto@google.com> |
Account refactoring follow-up - Check if there's really a new or removed account in updateAccountsInBackground() before doing everything else. If there's none, we'll skip re-scanning directories too. - Preheat the account cache when the provider starts. - Use account_id for the account filter query parameters. The contacts URI now supports the parameters too. Change-Id: I12e1116890df4c20b354618acfaee9dc009dc68e
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/ContactsDatabaseHelperTest.java
|
9d990d339c9e3a9e03f6fe13c260d36665f00e61 |
|
16-Dec-2011 |
Makoto Onuki <omakoto@google.com> |
Account table refactoring - Remove the account columns (type, name, data_set) from the raw_contacts/groups tables and add account_id instead. - Re-create the accounts table. The new table now has the _ID column. Rows in this table now has a different lifecyle than before: -- New row is created as the provider detects a new account during a write operation to the raw_contacts and groups table. -- Stale rows are removed upon account removal. - Removed account consistency check for steam items/photos. We don't do this kind of check for other tables. Change-Id: I1ce01590aef70f417fa89426dae762a41d25d656
/packages/providers/ContactsProvider/tests/src/com/android/providers/contacts/ContactsDatabaseHelperTest.java
|