In D17887#384686, @staniek wrote:

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

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...

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().

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().

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

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.

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.

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.

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.

In D17887#384384, @pino wrote:

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

@piggz Done in kexi.git: D17847.

In D17336#382812, @piggz wrote:

Following BT when doing the action:
Open database
Right click on query and select Design
When prompted that cannot open in design view, select option to open in text view
Crash

P.S. i got query to work by arranging date as yyyy-mm-dd .... i had used dd-mm-yyyy

Following BT when doing the action:
Open database
Right click on query and select Design
When prompted that cannot open in design view, select option to open in text view
Crash

In D17336#382289, @piggz wrote:

I tested a simple expression, such as
select #date# as expr1
and it worked
But a more complex query such as
SELECT mi_band_activity.*, timestamp_dt FROM mi_band_activity where timestamp_dt > #23-May-2018#

I tested a simple expression, such as
select #date# as expr1
and it worked
But a more complex query such as
SELECT mi_band_activity.*, timestamp_dt FROM mi_band_activity where timestamp_dt > #23-May-2018#
does not work, gives the following output:
org.kde.kdb.core: checking variable name: "mi_band_activity.*"
org.kde.kdb.core: checking variable name: "timestamp_dt"
org.kde.kdb.core: checking variable name: "timestamp_dt"
org.kde.kdb.core: error:
org.kde.kdb.core: at character 95 near tooken "#"
org.kde.kdb.core: KDbEscapedString:"SELECT mi_band_activity.*, timestamp_dt FROM mi_band_activity where timestamp_dt > #23-05-2018#"

@piggz Sorry, updated now, I had to type arc diff --update D17336 --no-amend.

• GIT_SILENT KDb VERSION 3.1.1
• Add Date/Time classes for precise type support
• Add autotests for the KDb date/time classes
• Add support for the Date/Time constants in the SQL parser
• Add autotests for date/time related KDBSQL statements
• Merge remote-tracking branch 'origin/3.1' into 393094-date-constants
• Version 3.2.0
• Merge remote-tracking branch 'origin/3.2' into 393094-date-constants
• Merge branch '3.2' into 393094-date-constants

I used arc patch D17336 on kdb
I get errors like
org.kde.kdb.core: error: syntax error, unexpected $undefined, expecting $end
org.kde.kdb.core: at character 8 near tooken "#"
org.kde.kdb.core: KDbEscapedString:"select #2018-05-23#"
org.kde.kdb.core: " ^"

• Merge branch '3.2' into 393094-date-constants

• Version 3.2.0
• Merge remote-tracking branch 'origin/3.2' into 393094-date-constants

• Merge remote-tracking branch 'origin/3.1' into 393094-date-constants

• Add autotests for date/time related KDBSQL statements

In D13448#276358, @piggz wrote:

Other drivers affected?

Other drivers affected?

Add note that the bug is for SQLite

Surprising how many changes for one crash!

• MissingTableTest: call again with ok == nullptr and verify
• Rework KDbConnection::drv_getTableNames API so error information is passed

• MissingTableTest: call again with ok == nullptr and verify
• Rework KDbConnection::drv_getTableNames API so error information is passed

Pushed. Congratulations on first KEXI/KDb contribution!
https://phabricator.kde.org/R15:7e5633c36316cd8cf180eae982c5bc4574bb62bf

It's harindudilshan95@gmail.com .

OK I will, what's your email address?

As I don't have write access, would you please land it ?

Good job, thanks! Two things:

• Update README-PACKAGERS doc to reflect naming and notes about compatibility
• Bump soname to separate from incompatible 3.0 branch

• GIT_SILENT SDC file is really generated