Another option could be to resolve the mimetypes when loading the metadata of the plugins, in DriverManagerInternal::lookupDriversInternal().

An untested patch can be:

diff --git a/src/KDbDriverManager.cpp b/src/KDbDriverManager.cpp
index 0d35729c..1de8e9fe 100644
--- a/src/KDbDriverManager.cpp
+++ b/src/KDbDriverManager.cpp
@@ -30,6 +30,9 @@
 #include <KPluginFactory>
 
 #include <QApplication>
+#include <QMimeDatabase>
+#include <QMimeType>
+#include <QSet>
 #include <QTime>
 #include <QWidget>
 
@@ -102,6 +105,7 @@ void DriverManagerInternal::lookupDriversInternal()
             = KDbJsonTrader::self()->query(QLatin1String("KDb/Driver"));
     const QString expectedVersion = QString::fromLatin1("%1.%2")
             .arg(KDB_STABLE_VERSION_MAJOR).arg(KDB_STABLE_VERSION_MINOR);
+    QMimeDatabase mimedb;
     foreach(const QPluginLoader *loader, offers) {
         //QJsonObject json = loader->metaData();
         //drivermanagerDebug() << json;
@@ -123,7 +127,18 @@ void DriverManagerInternal::lookupDriversInternal()
             }
             continue;
         }
+        QSet<QString> resolvedMimeTypes;
         foreach (const QString& mimeType, metaData->mimeTypes()) {
+            const QMimeType mime = mimedb.mimeTypeForName(mimeType);
+            if (!mime.isValid()) {
+                kdbWarning() << "Driver with ID" << metaData->id()
+                             << "supports the unknown mimetype"
+                             << mimeType << "-- skipping it";
+                continue;
+            }
+            resolvedMimeTypes.insert(mime.name());
+        }
+        foreach (const QString& mimeType, resolvedMimeTypes) {
             m_metadata_by_mimetype.insertMulti(mimeType, metaData.data());
         }
         m_driversMetaData.insert(metaData->id(), metaData.data());

The QSet is used to avoid that the same metadats is registered twice in m_metadata_by_mimetype for the same mimetype, in case a plugin specifies two entries (mime name and one alias of it).

In D17887#384384, @pino wrote:

The QSet is used to avoid that the same metadats is registered twice in m_metadata_by_mimetype for the same mimetype, in case a plugin specifies two entries (mime name and one alias of it).

Thanks. Interesting though m_metadata_by_mimetype.insertMulti(mimeType, metaData.data()) is used for a purpose, it's valid case to have multiple plugins supporting the same type. Even if for now it's not widely used possibility. KEXI has a special TODO for that - asking the user to pick driver (handler) for given type if there are multiple options. Currently we're picking first on the list.

In D17887#384409, @staniek wrote:

In D17887#384384, @pino wrote:

The QSet is used to avoid that the same metadats is registered twice in m_metadata_by_mimetype for the same mimetype, in case a plugin specifies two entries (mime name and one alias of it).

Thanks. Interesting though m_metadata_by_mimetype.insertMulti(mimeType, metaData.data()) is used for a purpose, it's valid case to have multiple plugins supporting the same type.

Let me explain this better -- the situation fixed by using the QSet is:

• a plugin has application/x-foo, and application/x-foo-alias as MimeTypes
• application/x-foo-alias is an alias of application/x-foo
• directly inserting in m_metadata_by_mimetype the result of the mime type resolution means that m_metadata_by_mimetype will have the metadata of this plugin twice for the same key (application/x-foo)

My draft of patch does not change at all the fact that different plugins can register for the same mimetype.

Ah your test is for something else than I wrote above and might be useful but I just learned that we never know (like in the case of the linked FD.o change) what happens on user's OS and whether the OS provide type alias or regular type as a result of detection. So I'd be safer if we handle all mime types and aliases declared by the plugins.

m_metadata_by_mimetype's key is string so application/x-foo and application/x-foo-alias are two different keys that here point to the same plugin. User's code is free to ask about either type by name.

In D17887#384418, @staniek wrote:

Ah your test is for something else than I wrote above and might be useful but I just learned that we never know (like in the case of the linked FD.o change) what happens on user's OS and whether the OS provide type alias or regular type as a result of detection. So I'd be safer if we handle all mime types and aliases declared by the plugins.

This is exactly what my patch does... in case any of the mimetypes specified by the kdb plugins will become an alias, kdb will still handle that.
The second part of the patch is, if needed, that whatever calls KDbDriverManager::driverIdsForMimeType() ought to better pass resolved mimetypes too.

OK, second attempt (still untested!), resolving mimetypes on lookup:

diff --git a/src/KDbDriverManager.cpp b/src/KDbDriverManager.cpp
index 0d35729c..297910b4 100644
--- a/src/KDbDriverManager.cpp
+++ b/src/KDbDriverManager.cpp
@@ -30,6 +30,9 @@
 #include <KPluginFactory>
 
 #include <QApplication>
+#include <QMimeDatabase>
+#include <QMimeType>
+#include <QSet>
 #include <QTime>
 #include <QWidget>
 
@@ -102,6 +105,7 @@ void DriverManagerInternal::lookupDriversInternal()
             = KDbJsonTrader::self()->query(QLatin1String("KDb/Driver"));
     const QString expectedVersion = QString::fromLatin1("%1.%2")
             .arg(KDB_STABLE_VERSION_MAJOR).arg(KDB_STABLE_VERSION_MINOR);
+    QMimeDatabase mimedb;
     foreach(const QPluginLoader *loader, offers) {
         //QJsonObject json = loader->metaData();
         //drivermanagerDebug() << json;
@@ -123,7 +127,18 @@ void DriverManagerInternal::lookupDriversInternal()
             }
             continue;
         }
+        QSet<QString> resolvedMimeTypes;
         foreach (const QString& mimeType, metaData->mimeTypes()) {
+            const QMimeType mime = mimedb.mimeTypeForName(mimeType);
+            if (!mime.isValid()) {
+                kdbWarning() << "Driver with ID" << metaData->id()
+                             << "supports the unknown mimetype"
+                             << mimeType << "-- skipping it";
+                continue;
+            }
+            resolvedMimeTypes.insert(mime.name());
+        }
+        foreach (const QString& mimeType, resolvedMimeTypes) {
             m_metadata_by_mimetype.insertMulti(mimeType, metaData.data());
         }
         m_driversMetaData.insert(metaData->id(), metaData.data());
@@ -162,7 +177,12 @@ QStringList DriverManagerInternal::driverIdsForMimeType(const QString &mimeType)
     if (!lookupDrivers()) {
         return QStringList();
     }
-    const QList<KDbDriverMetaData*> metaDatas(m_metadata_by_mimetype.values(mimeType.toLower()));
+    QMimeDatabase mimedb;
+    const QMimeType mime = mimedb.mimeTypeForName(mimeType);
+    if (!mime.isValid()) {
+        return QStringList();
+    }
+    const QList<KDbDriverMetaData*> metaDatas(m_metadata_by_mimetype.values(mime.name()));
     QStringList result;
     foreach (const KDbDriverMetaData* metaData, metaDatas) {
         result.append(metaData->id());

Thanks Pino. Your patch adds some future-proof, I would adapt it. But I yet have to see how the problem is solved without patching of the json file. If I understand correctly if we do not explicitly list "application/vnd.sqlite3" in the JSON, current FD.o master https://cgit.freedesktop.org/xdg/shared-mime-info/commit/freedesktop.org.xml.in?id=36a88b01f6ae90da35a2f6a072db159c84cea768 resolves "application/vnd.sqlite3" into "application/x-kexiproject-sqlite3" only if we go to parent mime type "application/x-sqlite3" which is alias of real parent "application/vnd.sqlite3". I see that "application/x-kexiproject-sqlite3" has room for improvements. I do not see that we use QMimeType::parentMimeTypes().

So for me the full fix is to work as expected also on such half-configured systems (so all updated Linux systems became problematic). I am going to even go further and fall back to the sqlite3 plugin when mime database gives no hint at all what the file is. At KDb or KEXI level, preferably KEXI level.

Happy new year :)

In D17887#384476, @staniek wrote:

If I understand correctly if we do not explicitly list "application/vnd.sqlite3" in the JSON, current FD.o master https://cgit.freedesktop.org/xdg/shared-mime-info/commit/freedesktop.org.xml.in?id=36a88b01f6ae90da35a2f6a072db159c84cea768 resolves "application/vnd.sqlite3" into "application/x-kexiproject-sqlite3" only if we go to parent mime type "application/x-sqlite3" which is alias of real parent "application/vnd.sqlite3". I see that "application/x-kexiproject-sqlite3" has room for improvements. I do not see that we use QMimeType::parentMimeTypes().

I don't see what parent mimetypes have anything to do with this. There is no parent lookup neither "is a" checking in the plugin loader, all it does is "supports this mimetype".
Do not overthink the issue, really...

In D17887#384666, @pino wrote:

In D17887#384476, @staniek wrote:

If I understand correctly if we do not explicitly list "application/vnd.sqlite3" in the JSON, current FD.o master https://cgit.freedesktop.org/xdg/shared-mime-info/commit/freedesktop.org.xml.in?id=36a88b01f6ae90da35a2f6a072db159c84cea768 resolves "application/vnd.sqlite3" into "application/x-kexiproject-sqlite3" only if we go to parent mime type "application/x-sqlite3" which is alias of real parent "application/vnd.sqlite3". I see that "application/x-kexiproject-sqlite3" has room for improvements. I do not see that we use QMimeType::parentMimeTypes().

I don't see what parent mimetypes have anything to do with this. There is no parent lookup neither "is a" checking in the plugin loader, all it does is "supports this mimetype".
Do not overthink the issue, really...

Shorter: what change in kdb_sqlitedriver.json do you propose?

In D17887#384686, @staniek wrote:

Shorter: what change in kdb_sqlitedriver.json do you propose?

With the draft of patch I proposed, none.

In D17887#384687, @pino wrote:

In D17887#384686, @staniek wrote:

Shorter: what change in kdb_sqlitedriver.json do you propose?

With the draft of patch I proposed, none.

OK but that means you propose to revert change for the json or keeping the change as is?

I need to double check we understand if (and how) the plugin is properly detected in two cases:

1. Old case: before the critical FD.o change - it works because .kexi files' mimetype is "application/x-sqlite3"
2. New case: after the the critical FD.o change when .kexi files' mimetype is application/vnd.sqlite3 - this is the case of https://bugs.kde.org/show_bug.cgi?id=396999 - how would it work?

Both using the same code.

In D17887#384699, @staniek wrote:

In D17887#384687, @pino wrote:

In D17887#384686, @staniek wrote:

Shorter: what change in kdb_sqlitedriver.json do you propose?

With the draft of patch I proposed, none.

OK but that means you propose to revert change for the json or keeping the change as is?

My patch instead of this.

I need to double check we understand if (and how) the plugin is properly detected in two cases:

1. Old case: before the critical FD.o change - it works because .kexi files' mimetype is "application/x-sqlite3"
2. New case: after the the critical FD.o change when .kexi files' mimetype is application/vnd.sqlite3 - this is the case of https://bugs.kde.org/show_bug.cgi?id=396999 - how would it work?

Using my patch (v2), the mimetypes claimed by every plugin are always registered as their real names (i.e. resolving possible aliases). When loading a plugin via mimetype, the code finds the real name of the requested mimetype (i.e. resolving possible aliases), and uses it to get the plugin for it (if available).

The sqlitedriver plugin claim to support two mimetypes, and this will not change.

Tested before and after adding application/vnd.sqlite3 to the system (exact FD.o patch) - it works only thanks to keeping the old x-sqlite3 type in the JSON and because FD.o has an alias. Good that I asked about json, otherwise it would fail for me. Added more extensive tests to verify. Thanks @pino and be welcome to more reviews :)

I don't understand what is tested in KDbTestUtils::testDriver() now, related to the mimetypes. The old logic looked better (and simpler too) to me, I'd just leave that.
The only simple addition IMHO is that manager.driverIdsForMimeType(mimeName) returns a valid driver for each of the mimetypes specified in the plugin metadata.

Also, the commit message needs to be updated to just say that mimetypes are always resolved in the driver manager, so even if a mimetype claimed by a driver becomes an alias the plugin is still loaded.

In D17887#384770, @pino wrote:

I don't understand what is tested in KDbTestUtils::testDriver() now, related to the mimetypes. The old logic looked better (and simpler too) to me, I'd just leave that.
The only simple addition IMHO is that manager.driverIdsForMimeType(mimeName) returns a valid driver for each of the mimetypes specified in the plugin metadata.

Two things:

• the original logic of the patch completely missed checks of driverIdsForMimeType(), it is also not present in 3.2 branch
• the issue with invalid mimetypes on testing OS

Also, the commit message needs to be updated to just say that mimetypes are always resolved in the driver manager, so even if a mimetype claimed by a driver becomes an alias the plugin is still loaded.

It's good idea for the API docs, I'll add.

@piggz
Pushed for 3.2 Beta, post-commit review would be welcome.