Error contact reading
Simon Redman
simon at ergotech.com
Sat Oct 19 18:55:19 BST 2019
As usual, Albert was right :)
We already have to do the second round of accesses one-by-one because
the batch-access vcard API doesn't work. I had forgotten this.
I have changed the lookup to be the way Albert suggested, where it
either looks up the timestamp for all contacts without specifying each,
or it looks up exactly one.
Merge request:
https://invent.kde.org/kde/kdeconnect-android/merge_requests/103
On 10/17/19 9:38 PM, Simon Redman wrote:
> To explain another point that I think might be causing confusion:
> I agree that the problem in this case is too many variables and not
> too many results. However, once we get the results from this function,
> it gets fed in to another function to get the actual data.
>
> On 10/17/19 9:31 PM, Simon Redman wrote:
>> Batch accesses are faster than single accesses. I haven't tried it
>> for contacts, but one time when I went to one-by-one access for SMS
>> it was like 15x slower.
>>
>> On the other hand, I have thousands of text messages and only a
>> couple hundred contacts, so the problem is less. My suggestion would
>> be to break it in to batches of 75 (to pick a random number that I'm
>> pretty sure is safe). Probably in ContactsHelper.getVCardsForContactIDs.
>>
>> I will try to do this this weekend but if someone else beats me to it
>> I won't be hurt :)
>>
>> Thanks,
>> Simon
>>
>> On 10/16/19 10:15 AM, Albert Vaca Cintora wrote:
>>> I don't see any use of this function that isn't with either a single
>>> contact or all the contacts (correct me if I'm wrong). The "too many
>>> variables" would be avoided by having a method that in the second
>>> case just doesn't use a "where in", because the problem is too many
>>> variables and not too many results.
>>>
>>> On Mon, Oct 14, 2019, 07:06 Simon Redman <simon at ergotech.com
>>> <mailto:simon at ergotech.com>> wrote:
>>>
>>> Yes, probably we could do this. The trouble is that for the
>>> first time running synchronization the desktop would then call
>>> this method with the complete list of changed contacts. Since it
>>> is first sync, it would be all of them, thus it would have the
>>> same problem.
>>>
>>> So the simplest solution would be to just break it in to batches
>>> since this solves both cases. But what is a safe batch size?
>>>
>>> On October 12, 2019 12:01:53 PM PDT, Albert Vaca Cintora
>>> <albertvaka at gmail.com <mailto:albertvaka at gmail.com>> wrote:
>>>
>>> Or even, if we are requesting *all* the IDs, I guess we could remove
>>> the `WHERE ID IN()` in that call?
>>>
>>> On Sat, Oct 12, 2019 at 9:00 PM Albert Vaca Cintora
>>> <albertvaka at gmail.com <mailto:albertvaka at gmail.com>> wrote:
>>>
>>> Actually here is the call for all the IDs [1], the
>>> previous one only requests a single ID.
>>> https://invent.kde.org/kde/kdeconnect-android/blob/master/src/org/kde/kdeconnect/Plugins/ContactsPlugin/ContactsPlugin.java#L196
>>> On Sat, Oct 12, 2019 at 8:57 PM Albert Vaca Cintora
>>> <albertvaka at gmail.com <mailto:albertvaka at gmail.com>> wrote:
>>>
>>> It looks like in getColumnsFromContactsForIDs [1] we
>>> are passing to many IDs. A solution probably would
>>> be we could request them in smaller batches.
>>> https://invent.kde.org/kde/kdeconnect-android/blob/master/src/org/kde/kdeconnect/Plugins/ContactsPlugin/ContactsPlugin.java#L161
>>> On Sat, Oct 12, 2019 at 7:19 PM Simon Redman
>>> <simon at ergotech.com <mailto:simon at ergotech.com>> wrote:
>>>
>>> Hmm. I have no idea what is causing this (since
>>> it's below Android's "we're totally not using a
>>> sqlite database" layer) Is this reliably
>>> reproducible? (If so, how?) On 10/12/19 8:48 AM,
>>> Aleix Pol wrote:
>>>
>>> Hey Simon, I was looking at adb logs, I saw
>>> this error, maybe you can take a look. 10-12
>>> 17:36:27.053 29958 2983 E KDE/Device:
>>> android.database.sqlite.SQLiteException: too
>>> many SQL variables (code 1): , while
>>> compiling: SELECT lookup,
>>> contact_last_updated_timestamp FROM
>>> view_contacts WHERE ((1)) AND (lookup
>>> IN(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,
>>> ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?))
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:179)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:135)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> android.content.ContentProviderProxy.query(ContentProviderNative.java:418)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> android.content.ContentResolver.query(ContentResolver.java:754)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> android.content.ContentResolver.query(ContentResolver.java:704)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> android.content.ContentResolver.query(ContentResolver.java:662)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Helpers.ContactsHelper.getColumnsFromContactsForIDs(ContactsHelper.java:307)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Plugins.ContactsPlugin.ContactsPlugin.handleRequestAllUIDsTimestamps(ContactsPlugin.java:196)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Plugins.ContactsPlugin.ContactsPlugin.onPacketReceived(ContactsPlugin.java:253)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Device.onPacketReceived(Device.java:569)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Backends.BaseLink.packageReceived(BaseLink.java:84)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Backends.LanBackend.LanLink.receivedNetworkPacket(LanLink.java:255)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Backends.LanBackend.LanLink.lambda$reset$0$LanLink(LanLink.java:109)
>>> 10-12 17:36:27.053 29958 2983 E KDE/Device:
>>> at
>>> org.kde.kdeconnect.Backends.LanBackend.-$$Lambda$LanLink$TabvaCXA5qL_bcJDmIELWusNThw.run(Unknown
>>> Source:4) 10-12 17:36:27.053 29958 2983 E
>>> KDE/Device: at
>>> java.lang.Thread.run(Thread.java:764)
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20191019/7f3d2dee/attachment.html>
More information about the KDEConnect
mailing list