> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
