-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate entry for typename in carddav_xsubtypes #306
Comments
Hello, does this happen in a reproducible manner (e.g. every time you add the addressbook as a new one, or even on every sync)? |
Heh, it seems that it happens everytime I add the addressbook as a new one (I add several addressbooks at a time). I'll try with different carddav servers (baikal, nextcloud contacts, Sogo) to see what happens. The problem I described is with Nextcloud contacts, with 4 addressbooks. The fact is that in this case, I think that the SQL INSERT statement should be an UPSERT. I have to look into my DB to see what provokes the conflict. |
Normally this insert only happens when a new custom label (X-ABLabel extension) is encountered in an addressbook. When the label is already known, it should not attempt to insert it again. I know this conflict might happen when you have concurrent sync operations running on the same addressbook, but in this case it would be harmless / just a log entry. Anyway, I will recheck the code concerning X-ABLabel again and try myself with an addressbook that has multiple uses of the same custom label to see if I can reproduce the issue. |
Thanks @mstilkerich , I forgot to mention that I miss a lot of contacts on the RC side, and I think it blocks always at the same contact. I have to investigate (when I'll have time :p) which one blocks ;) |
So I have taken a look, but I don't see how this situation could happen except for said concurrent synchronizations, which I don't think is happening in your case if the problem occurs during every sync. I have also tried myself with adressbooks that contain several cards with the same special label, and also cards that use the same special label on several email addresses. Unfortunately, I cannot reproduce the issue. To give you a bit of context in case you cannot guess it from the log messages: In VCard, you can assign any multi-value attribute (in this case, Then there is an extension to VCard (I believe originally defined by Apple from the name) called Now the roundcube contact edit mask only allows to select the type of a multi-value attribute from a dropdown list, it is not possible to create new user-defined labels. To support user-defined labels, the rcmcarddav plugin stores any special label encountered in an addressbook in the database, and adds it to that dropdown list so it is possible to assign the label to other multi-value properties of the same time (email addresses in this case). This database store operation only happens for new labels, i. e. that are not already inside the database for the respective addressbook. In your case, the database store operation is attempted although the label is apparently already stored inside the DB for that addressbook. This fails because of a DB UNIQUE constraint. However, I have no explanation as to why the plugin attempts to store a label that is already inside the DB. If possible, can you provide the offending VCard? You should be able to find it in carddav_http.log when the loglevel for HTTP is set to debug by searching for X-ABLabel in the logfile. I just came across a potential issue that I have to try: Are you using MySQL? In MySQL, we use case-insensitive collations, so the issue might occur if the label is used with different casing (for example OLD and old). |
Yep, special label with different case triggers the problem with MySQL because of the case insensitive collations. So I guess you have several different spellings of the OLD label for email addresses in your addressbook. |
Thanks a lot @mstilkerich , I removed the problematic X-label OLD and old types, and now everything is going well! |
This happens when updating a new carddav addressbook, with the latest version of Roundcube (1.4.9) and RCMCardDav (from composer, 4.0.0)
Log
The text was updated successfully, but these errors were encountered: