[Kde-pim] MailTransport sendmail related Akonadi error

[Daniel Vratil]

On Thursday 09 of October 2014 21:32:12 David Jarvie wrote:
> On Thursday 09 Oct 2014 10:44:05 Daniel Vratil wrote:
> > On Monday 06 of October 2014 23:55:33 David Jarvie wrote:
> > > When I try to send a mail (in KAlarm) using sendmail,
> > > MailTransport::MessageQueueJob returns an error "Unable to add item
> > > part".
> > > This is from an ItemCreateJob set up in
> > > MessageQueueJob::Private::outboxRequestResult(). Can anybody help as to
> > > why
> > > this is happening? I attach the output shown in the akonadiconsole
> > > Debugger
> > > (saved as rich text) and Query Debugger tabs. The errors can be seen at
> > > the
> > > end of each log file.
> > 
> > Hi,
> > 
> > from the logs I deduced that you are using Akonadi 1.12. There seems to be
> > 
> > something very weird with your MySQL database:
> >  "Error: Duplicate entry '56-' for key 'PartTable_pimItemIdNameIndex' 
QMYSQL3:
> > Unable to execute statement "
> > 
> > PimItemId - Name is a UNIQUE index in PartTable - except for that "name"
> > column has been removed from PartTable in 1.12, so you should not have
> > this
> > index at all. The index apparently was not removed for some reason, and
> > now it behaves as a unique index for the PimItemId column only, which
> > prevents Akonadi from appending more than one Part to each item. I'm
> > wondering how Akonadi can work at all for you...
> > 
> > To fix this, run
> > 
> > DROP INDEX PartTable_pimItemIdNameIndex ON PartTable
> > 
> > from Akonadi console (or just connect to MySQL directly), that should fix
> > things.
> 
> Thanks - that fixed it. The Akonadi version may be a bit mixed up - the
> database may have originally been created with 1.12, but I haven't run 1.12
> for quite some time. I quite often accidentally run version 1.7, which is
> my distro's installed version, and then have to restart the server using
> 1.13 for KDE development.
> 
> It does concern me that PIM functions which depend on Akonadi can be
> disabled because of database weirdness. It would be very desirable for
> there to be database validation (on server startup perhaps?) which would
> either fix errors automatically, or at the very least report them and tell
> the user how to fix them (preferably without having to resort to manual
> methods such as akonadiconsole). I don't know how practical this is, but it
> might prevent a number of users giving up on Akonadi.

We have that: on each start Akonadi checks whether all tables are present (or 
creates missing), whether their schema is up-to-date (or updates it) and 
whether all indexes are there (or creates them). We don't have code that would 
remove indexes that are not supposed to exist, as we try not to remove stuff 
that we don't know where it came from. Plus that should only happen when you 
are mixing versions of Akonadi on top of the same database


Dan

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141010/0eb113d4/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/