使用ContentResolver無法進(jìn)行distinct查詢的解決方法

1、使用contentresolver無法進(jìn)行distinct查詢的解決方法場(chǎng)景假定：一個(gè)聯(lián)系人a有兩個(gè)電話號(hào)碼，分離是32111268和32111269。現(xiàn)在要對(duì)聯(lián)系人的電話舉行查詢，以得到聯(lián)系人的raw_contact_id。（ps：_不錯(cuò)的開發(fā)溝通群：314230976，驗(yàn)證：eec，有愛好的話可以加入進(jìn)來一起研究）我們知道，在android系統(tǒng)中，全部和聯(lián)系人有關(guān)的數(shù)據(jù)，都存儲(chǔ)在數(shù)據(jù)庫 /data/data/viders.contacts/databases/contacts2.db里面的data數(shù) 據(jù)表中，因此，可以對(duì)該表舉行查詢以獲得聯(lián)系人的raw_con

2、tact_id。對(duì)于上面假定的狀況，在data數(shù)據(jù)表中和聯(lián)系人a有關(guān)的電話記錄有兩 條，大致如下： |as raw_contact_id| |32111268| |as raw_contact_id| |32111269| 很明顯，這兩個(gè)電話號(hào)碼屬于同一個(gè)聯(lián)系人?，F(xiàn)在假定我們要查詢電話號(hào)碼中包含“32111”的聯(lián)系人，在sqlite指令行下可以這么寫(假定按raw_contact_id排序)：1 select distinct raw_contact_id fromdata where mimetype_id = 5 anddata1 like 2111% order by raw_conta

3、ct_id;這樣就會(huì)得到唯一的as raw_contact_id但是假如寫成：1 select raw_contact_id from data wheremimetype_id = 5 and data1 like2111% order by raw_contact_id;得到的結(jié)果就是：as raw_contact_idas raw_contact_id這明顯不符合要求，由于對(duì)于同一個(gè)聯(lián)系人的raw_contact_id，我們不希翼在查詢結(jié)果中浮現(xiàn)兩次。這就是為什么在前面一條sql語句中加上distinct的緣由。在我們自己的android應(yīng)用中，要對(duì)contacts2.db舉行拜訪舉行拜

4、訪， 只能通過contentresolver對(duì)象，這是由于contacts2.db不屬于我們自己的android應(yīng)用進(jìn)程，因此，無法得到和 contacts2.db相關(guān)的sqlitedatabase對(duì)象，進(jìn)而無法調(diào)用sqlitedatabase中的execsql辦法去執(zhí)行上面的sql 語句。同時(shí)，我們?cè)谟梅╟ontentresolver對(duì)象對(duì)data數(shù)據(jù)表舉行查詢的時(shí)候，無法用法distinct關(guān)鍵字!這就是說，假如一個(gè)聯(lián)系人 有兩個(gè)電話號(hào)碼符合查詢條件，那么該聯(lián)系人的raw_contact_id就會(huì)在返回的cursor對(duì)象中浮現(xiàn)兩次!下面的寫法01 contentresolver resol

5、ver = context.getcontentresolver();0203 cursor cursor = resolver.query(data.content_uri,0405 newstringdata.raw_contact_id, / 竟然不支持distinct，假如在這里加上distinct將會(huì)浮現(xiàn)錯(cuò)誤！0607 data.mimetype + " = '"+ phone.content_item_type + "' and "+ data.data1 + "like '2111%' "

6、,0809 null,1011 data.raw_contact_id);和前面的1 select raw_contact_id from data wheremimetype_id = 5 and data1 like2111% order by raw_contact_id;所得到的結(jié)果是一樣的，會(huì)得到兩個(gè)千篇一律的a raw_contact_id，這明顯不符合要求。那么怎么辦呢?我們知道java中set具有“a collection that contains no duplicate elements”，也就是說set中的元素是唯一的，當(dāng)調(diào)用add辦法，往set對(duì)象加入對(duì)象時(shí)，假如被加

7、的對(duì)象已經(jīng)在set中存在，那么該對(duì)象將不會(huì) 被再次加入，以保證該對(duì)象在set中的唯一性。為此，在上面代碼的基礎(chǔ)上，可以考慮用法實(shí)現(xiàn)了set接口的hashset。1 hashset hashset = newhashset();2 / 用這種方式(set)來保證唯一性34 while(cursor.movetonext()5 hashset.add(cursor.getint(0);6 復(fù)制代碼這樣一來，在hashset中的as raw_contact_id就惟獨(dú)一個(gè)了，也就是說通過這種方式，變通地實(shí)現(xiàn)了distinct這個(gè)sql關(guān)鍵字的語義。固然，這樣會(huì)增強(qiáng)額外的處理時(shí)光，在一個(gè)有1200條記

8、錄，其中電話記錄有710條的 data數(shù)據(jù)表中，上面的操作耗時(shí)30ms左右(thinkpad t410, android 模擬器環(huán)境下)，對(duì)于一般的和聯(lián)系人有關(guān)的應(yīng)用而言，30ms的延遲算不了什么事件，因此這種變通的方式應(yīng)當(dāng)是可行的。個(gè)人感覺，android系統(tǒng)自帶的聯(lián)系人數(shù)據(jù)庫及其contentresolver 在無數(shù)時(shí)候都還算比較方面，但同樣在無數(shù)狀況下，也存在很顯然的限制。對(duì)于喜愛自己寫sql語句的伴侶而言，這種限制幾乎是難以忍受的，比如無法通過 contentresolver在contacts2.db中增強(qiáng)觸發(fā)器(在sqlite指令行下是可以的，但這樣對(duì)于要發(fā)布的和聯(lián)系人有關(guān)的引用而言， 這樣做是不合適的)等等。進(jìn)而言之，sqlite這個(gè)數(shù)據(jù)庫簡(jiǎn)明扼要，包含的特點(diǎn)也算不少，總體說來相當(dāng)不錯(cuò)，否則也就沒有那么多公司采納它了。但同時(shí)也存在諸多不足：1. 不支持存儲(chǔ)過程;2. 用c、c+可以比較便利地開發(fā)類似于存儲(chǔ)函數(shù)之類的東西(就是在sql語句中可以用法的那種函數(shù))，但用java做同樣的事情就相對(duì)很棘手;3. 在觸發(fā)器內(nèi)，不能顯式地執(zhí)行事務(wù)處理;4. 無法預(yù)先制定觸發(fā)器的觸發(fā)執(zhí)行挨次。這個(gè)從原理上來講，略微改動(dòng)一下源碼應(yīng)當(dāng)可以做到。5. 在缺省狀況下，插入數(shù)據(jù)的性能很糟糕。一秒鐘插入數(shù)據(jù)記錄的數(shù)量通常在20左右。用事務(wù)舉行