kde needs mysql-server ??

[Muayyad AlSadi]

> Ah, did you actually read http://techbase.kde.org/Projects/PIM/Akonadi?
> (Summary: they *did* consider sqlite, at least according to the FAQ)
>

yes I read it,


>Why not use sqlite?
> We tried. Really. It can't handle the concurrent access very well, in the best case this means very slow operations, but we've also seen deadlocks and failing transactions. Once that's fixed in sqlite, adjusting Akonadi to use it again instead of MySQL is no problem.

not convinced

I know that SQLite is not officiant for heavy concurrency
from http://www.sqlite.org/whentouse.html
Situations Where Another RDBMS May Work Better
High Concurrency

SQLite uses reader/writer locks on the entire database file. That
means if any process is reading from any part of the database, all
other processes are prevented from writing any other part of the
database. Similarly, if any one process is writing to the database,
all other processes are prevented from reading any other part of the
database. For many situations, this is not a problem. Each application
does its database work quickly and moves on, and no lock lasts for
more than a few dozen milliseconds. But there are some applications
that require more concurrency, and those applications may need to seek
a different solution.
EOQ

from http://www.sqlite.org/faq.html#q5

We are aware of no other embedded SQL database engine that supports as
much concurrency as SQLite. SQLite allows multiple processes to have
the database file open at once, and for multiple processes to read the
database at once. When any process wants to write, it must lock the
entire database file for the duration of its update. But that normally
only takes a few milliseconds.

EOQ

so I won't bother if it blocks for fraction of second when I'm doing
commits from more than one application

I bet that would be much faster than elephantine  RDBMS