summaryrefslogtreecommitdiffstats
path: root/src/com/android/providers/contacts/SearchIndexManager.java
Commit message (Collapse)AuthorAgeFilesLines
* Correctly append contact IDs in SearchIndexManagerYorke Lee2014-03-261-2/+2
| | | | | Bug: 11059351 Change-Id: I5d5193e37bf6cdbf059779f745cc73314c751962
* Update search index for entire contact when raw contact is modifiedYorke Lee2014-03-261-11/+13
| | | | | | Bug: 11059351 Change-Id: I7c8989fd8505f888f5bc8605e68a2d73d0142b76
* Fix PHONE_FILTER and CALLABLES_FILTER search behaviorYorke Lee2013-09-101-0/+4
| | | | | | | | | These two filters now only perform name lookups. The search index manager indexes names, nicknames, and organization title and company name for name lookups. Bug: 10680335 Change-Id: I283c61af64a2f104b7482a2819ed4b8a238cba04
* Rebuild SQLITE_STAT1 table after drop operations.Makoto Onuki2012-11-141-1/+1
| | | | | | | | | | | | | | | | | | | The SQLITE_STAT1 table has the estimated number of rows for each table and index, which is used to calculate a query plan for queries. The problem is that, DROP TABLE and DROP INDEX appear to remove the corresponding row from the stats table. This could cause SQLite to choose inefficient query plans. This CL will make sure to rebuild the stats table after such operations. Added a new boolean paramter rebuildSqliteStats to all methods that exectue DROP TABLE/INDEX. If it's set, they'll call updateSqliteStats() to rebuild the contents. Bug 7426624 Change-Id: I1c373b902856d1a24b6c0c8379899a235ee284c4
* Make sure to rebuild search index on locale changes...Makoto Onuki2012-10-011-3/+9
| | | | | | | | | | | | | | | | | so that search will still work even after changing the locale. - Rebuild the search index upon locale changes, as it contains locale-sensitive data. - Also make sure to update the in-memory collator in NameNormalizer upon locale changes. - Rebuild the search index on the next db upgrade in order to fix the search index which already contains invalid data. Bug 7251461 Change-Id: Id579a67de792a52a0091bf76d7c5d374f76f1639
* Reorganize import in contacts providerMakoto Onuki2012-06-271-8/+8
| | | | Change-Id: If3afb134ea36bd93859efcd114885526e1592b91
* Make names with special chars searchable.Makoto Onuki2012-04-301-37/+56
| | | | | | | | | | | | | | It's a better fix than I34bfa864, which was only a quick workaround for double barrelled names. Now names with other special characters are searchable too. Also, previously, a query "doublebarrelled" wouldn't match "double-barrelled", but now it will. Bug 5592553 Change-Id: Id1d44261f577df7abf701311ed1c86fb093547da
* New aggregation logicMakoto Onuki2012-04-201-14/+23
| | | | | | | | | | | | | | | | | | | Now a raw contact can be merged into a contact containing raw contacts from the same account if there's at least one raw contact in those raw contacts that shares at least one email address, phone number, or identity. Now the aggregation logic version is 3. Also: - Make sure changes to the identity triggers aggregation. - Stop re-using some HashMaps/HashSets, as they don't shirink the internal table when clear()ed. During the aggregation update we may put a bunch of stuff into those, and we want to make sure that we don't keep unnecessarily bit internal tables after the upgrade. This should be okay with the modern dalvik GC. Change-Id: I855085d334679363cf9bffb918ca2ceb0cfe77f5
* Use wall time instead of CPU time for performance logMakoto Onuki2012-03-081-2/+2
| | | | | | | | Apparently what currentThreadTimeMillis() returns is the CPU time, not wall time, which is not really interesting when we measure performance. Use the actual wall time instead. Change-Id: Ibe2e385ff1bdeeb1128a584c79925210dde5525a
* Speed up search query update after each transactionMakoto Onuki2012-01-201-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Contains two optimizations, which will greatly affect initial sync for an account with a large number of contacts. - When selecting from search_index, we used two columns from different tables: 'raw_contacts.contact_id IN (...) OR data.raw_contact_id IN (...)'. But this is really equivalent to '... OR raw_contacts._id IN (...)' as we inner join the two tables. The latter is pretty much faster as both columns are in the same table and each has an index. Bug 5842620 - When we replace a search_index row, we first try UPDATE and if no rows are affected then INSERT. But this UPDATE is pretty slow; on a test device it can easily take >10ms, and with a 10K contacts database it took >80ms. (INSERT is pretty fast; it's typically ~1ms.) Let's first bulk DELETE all affected rows, then INSERT. The DELETE takes roughly the same time as the previous UPDATE, but we only need 1 DELETE per transaction, not per row contact. Bug 5887648 Change-Id: I549ea2b47d7058bfba96a861236295f682d88c10
* Fix search for hyphenated namesMakoto Onuki2011-11-151-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This issue was caused by the combination of the fact that we have two different imcompatible tokenizers for names, and the fact that our name-normalizer ignroes all non-letter and non-digit characters. Basically, the name tokenizer used to build index uses ' ' as the separator, and the one used to tokenize queries use all non-letter, non-digit characters. Take the name "Double-barrelled" as an example. The full-text search index for this looks like "doublebarrelled", because it's treated as one token (because there's no spaces in it), and the normalzier removes all non-letter/digits. On the other hand, the query term "double-barrelled" will be split into "double" "barrelled", and internally it becomes AND-ed prefix matches "double* AND barrelled*". Beacuse "barrelled*" doesn't match "doublebarrelled" the query doesn't hit. So (for now) let's split names with '-' when buidling the index. With this CL the index will be "double barrelled" and the query "double-barrelled" (and also "double barrelled") *will* hit this. Long-term we probably need a better fix. Bug 5592553 Change-Id: I34bfa8647eec8d203f8ff7fc8a85f42505054c7c
* Use hexadecimal collation key for name searches.Daniel Lehmann2011-10-141-3/+119
| | | | | | | | Also allow prefix search on name Bug:5337763 Change-Id: I039264be0c8309224d8925ded06ab02a64a5ce1b
* Make search aware of names in "all other contacts"Daisuke Miyakawa2011-09-211-4/+2
| | | | | | | | | default_directory doesn't contain contacts which are in "all other contacts" group (or people who are not in any group), while in search mode we want those names. Bug: 5336673 Change-Id: Ib77acdfa6968605a66561f0925d0aa81f4522bb9
* Full text search: email suggestionsDmitri Plotnikov2011-02-111-5/+19
| | | | | | | Also, removing a bunch of dead code Bug: 2078420 Change-Id: I2c0a9ddd8e60624049b39ac018f87bfabc6574c2
* Full text search: QSB supportDmitri Plotnikov2011-02-111-0/+1
| | | | | Bug: 2078420 Change-Id: I767ccecc856c0ae9ad74aafb3dac0de39b657e3c
* Full text search: removing organization from name lookupDmitri Plotnikov2011-02-101-5/+23
| | | | | | | | | It no longer needs to be in the name lookup table, because we now have it in the search index and we don't use it for aggregation. Bug: 2078420 Change-Id: Iaab128513ff29a38f97c7d880c2aae668a3ef865
* Full text search: updating search index on change of visibilityDmitri Plotnikov2011-02-101-6/+23
| | | | | | | | | When a contact becomes invisible, the search index will be cleared. When it becomes visible, the index will be built. Bug: 2078420 Change-Id: I1eea88d3d9babc891d112d15d9041d01c383f22f
* Full text search: no snippet when searching by nameDmitri Plotnikov2011-02-101-0/+8
| | | | | Bug: 2078420 Change-Id: Icdd38c9963accec117ce134ef5a13e08e5f07f05
* Full text search: building full index for all contactsDmitri Plotnikov2011-02-081-12/+70
| | | | | Bug: 2078420 Change-Id: Ief6db4f4ecc0b6e5adb37a0654a72383099dc138
* Full text search: adding remaining built-in data typesDmitri Plotnikov2011-02-081-0/+4
| | | | | Bug: 2078420 Change-Id: Ifbd67f5ed65c44c2521a4b4d48d90aab8d0c86d1
* Full text search: adding common data typesDmitri Plotnikov2011-02-081-21/+28
| | | | | Bug: 2078420 Change-Id: I0c48e1fef3473415d01280274599f0be5cc69b08
* Full text search: adding internal provider API.Dmitri Plotnikov2011-02-071-0/+220
Also, adding the very first data type to FTS: organization. Bug: 2078420 Change-Id: I64d6f6a63efc838c4c2c80d4311bcc23bae23a67
generated by cgit v1.1 at 2024-08-21 07:27:38 +0000