- 03 Aug, 2020 3 commits
-
-
-
Rename `areRequirementsAvailable` method to `isAvailable` and implement the method for DbConfigPostgresql too. Extract the code from `DbConfig::configuredDatabase` that selects the fallback to use to a new separate static method, `defaultAvailableDatabaseBackend` to be more clear about what that code does and simplify `configuredDatabase`. Now if Postgresql is expected to be used (because akonadi was built like that) but QPSQL is not available or the initdb/pg_ctl binaries don't exist, then we fallback to trying to use QSQLITE3. As with the `DbConfigMysql` change, if QSQLITE3 can't be used either, then the code will continue trying to use postgresql and fail as expected.
-
On SUSE Linux Enterprise Desktop (SLED) with the PackageHub repository enabled (which provides the KDE packages) the mysql package is not available, so there's no mysqld, and the QMYSQL driver can't be used. OTOH, SUSE Linux Enterprise Server (SLES) with the same PackageHub repository enabled has a mariadb package available which provides the mysqld binary. Since the akonadi-server package for SLES and SLED is the same, we can't just set DATABASE_BACKEND to SQLITE at buildtime and we need to choose a fallback at runtime, which is what this commit implements. If it's the first time akonadi starts and mysql is expected to be used, this commit checks if it's really usable, and if it's not, it checks if the QSQLITE3 driver is available and if it is, we fall back to it instead of using mysql. Since we need to find out if a DbConfig* object can be initialized before it's actually initialized, I added a bool storeSettings parameter to DbConfig::init(QSettings &) that can be used to try the initialization (find out available paths, etc.) without storing anything. Then I added two methods DbConfigMysql::areRequirementsAvailable and DbConfigSqlite::areRequirementsAvailable that check if the given object has the system requirements available. I didn't add it to DbConfigPostgresql because Postgresql isn't used by default in any case. Also, note that this check is only done the first time akonadi starts when it's not configured. Once it starts with mysql or sqlite3 this configuration is stored and used the next times without any further check.
-
- 02 Jul, 2020 1 commit
-
-
- 10 Aug, 2018 1 commit
-
-
Daniel Vrátil authored
-
- 04 Jun, 2017 1 commit
-
-
Laurent Montel authored
-
- 06 Jan, 2017 1 commit
-
-
Laurent Montel authored
-
- 03 Jan, 2017 1 commit
-
-
Laurent Montel authored
-
- 13 Oct, 2016 1 commit
-
-
Daniel Vrátil authored
-
- 14 May, 2016 1 commit
-
-
Laurent Montel authored
-
- 27 Aug, 2014 1 commit
-
-
Daniel Vrátil authored
Still not perfect, but at least we are ready for merging the client libraries here. We can tune the rest once this is done.
-
- 31 Jul, 2014 1 commit
-
-
This changes the coding style in the entire Akonadi repo to follow the new KDE PIM coding style (https://techbase.kde.org/Policies/Kdepim_Coding_Style)
-
- 17 Feb, 2014 1 commit
-
-
Daniel Vrátil authored
Since we now support loading of plugins, having only Akonadi namespace might not be enough, as plugins can easily clash (like Akonadi::TagAttribute from Akonadi and from kdepimlibs). It will also make it easier to differentiate classes once both server and client libs are in the same repo in KF5.
-
- 05 Nov, 2010 1 commit
-
-
Bjoern Ricks authored
journal mode = WAL. With these modes fsync() calls are reduced and queries (especially insert and update) should perform much faster then before.
-
- 23 Mar, 2010 1 commit
-
-
Bertjan Broeksema authored
svn path=/trunk/kdesupport/akonadi/; revision=1106656
-
- 08 Jan, 2010 1 commit
-
-
Tobias Koenig authored
that does configuration and initialization. svn path=/trunk/kdesupport/akonadi/; revision=1071669
-