Add info about usable "expression dialect" to filter dialog

[kannes]

The query builder used for entering filter expressions on vector layers now shows the supported expression dialect. This uses the new data provider methods introduced in #58781.

Sponsored by WhereGroup GmbH.

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 2fb714f)

[NyakudyaA]

Can we not also add a link to each provider type documentation to allow users to see navigate to the documentation page so that they can explore available options with a specific provider i.e
"The available options depends on the provider type and storage options. Please consult the provider documentation to see supported options i.e. For Geopackage https://gdal.org/en/latest/drivers/vector/gpkg.html#sql"

[nyalldawson]

There's actual gdal API to retrieve the SQL dialect in use - see OSGeo/gdal#6154

That would be more appropriate to use here

[kannes]

That looks great!

Can I simply assume that QGIS is built with GDAL 3.6+?

I will create the URLs and then link the different GDAL_DMD_SUPPORTED_SQL_DIALECTS to them.

[kannes]

Nice, GDAL also provides GDAL_DMD_HELPTOPIC with the path to the help file, e.g. "drivers/vector/ili.html"

My current state:

I am linking to /latest/ on the GDAL homepage, is that ok? I did not find version-specific docs.

The code is probably a total mess, I will look at it again tomorrow. Any change recommendations are welcome of course :)

I think removing the provider and storage type again would be good.

[agiudiceandrea]

Can I simply assume that QGIS is built with GDAL 3.6+?

INSTALL.md says: GDAL/OGR >= 3.2.0
qgis.org currently provides also QGIS for Ubuntu jammy with GDAL 3.4.1, Debian bullseye with GDAL 3.2.2, and macOS with GDAL 3.3.2.

[kannes]

Thank you for the feedback!

But I realised something and am not sure if this is going into a good direction because I introduced a "display of potential SQL dialects one could utilize if using GDAL directly" vs. what I really wanted which is "display of the SQL dialect in use by the provider filter".

The ILIKE operator is often the cause for confusion and frustration for users so I use it as example here. ILIKE is usable at least with PostgreSQL sources and - if one uses OGR SQL.

But I just realised that even if a layer has OGRSQL support, it will not necessarily be used. E.g. a GeoPackage will have NATIVE, OGRSQL and SQLITE and if I write a query involving ILIKE (e.g. "NAME" ILIKE 'foo' on world.gpkg, it will error:

• GUI says "An error occurred when executing the query, please check the expression syntax."
• Debug log says "ERROR 1: sqlite3_prepare_v2(SELECT Count(*) FROM "countries" WHERE "NAME" ILIKE 'foo') failed: near "ILIKE": syntax error"

I assume that the native dialect is preferred (which makes great sense) but I could not figure it out from the sources.

So now I worry if this PR would introduce more confusion than help... It should display the dialect that is actually used, instead of the dialects that the user could use if they were using GDAL directly. As far as I know there is no way for the user to specify the SQL dialect to use, so theoretical support is irrelevant and misleading.

So I would rather remove the dialects display again.

---

(Ideally the user could select the utilized dialect themselves, e.g. with a dropdown list. But that would require much more work.)

[nyalldawson]

@kannes

display of the SQL dialect in use by the provider filter".

The first value returned from the metadata value is always the default, which will be the one QGIS uses

[nyalldawson]

@kannes I've taken the opportunity to add proper API for this up at the QgsDataProvider level -- see #58781 . I'd suggest rebasing this PR when #58781 is merged and then using those methods in the dialect, as it will get you nice strings + urls for all providers which support subseting.

[kannes]

Oh fantastic, thank you! I will try to finish this asap.

[kannes]

Done! This is really cool, thank you so much.

The text above the expression widget now just reads "Enter a [...] to filter the layer", where the appropriate name will be inserted as a hyperlink to the URL.

I decided to still add a visible information about the provider in use to the dialog, now right after the layer name at the topmost label.

Showing the storage type too seems not that useful to me anymore so I have not kept that.

New screenshots are in the main post above.

@nyalldawson are you sure that those dialects & URLs are all correct? For WFS it says "WFS query expression" and links to https://docs.ogc.org/is/09-025r2/09-025r2.html#83 but I have never seen a XML string used for a subset string. And for filtering WFS on load, the SQL Query composer exists, which uses SQL again (https://gis.stackexchange.com/questions/236847/tutorial-for-wfs-connection-sql-query-composer)

[rouault]

For WFS it says "WFS query expression" and links to https://docs.ogc.org/is/09-025r2/09-025r2.html#83 but I have never seen a XML string used for a subset string

the WFS provider can understand a subset of SQL WHERE clause or SQL SELECT as valid subsetStrings. I can't think of existing documentation where this clearly defined

Examples from unit tests:

        vl.setSubsetString('intfield = 2')
        vl.setSubsetString(
            "SELECT o.*, m.id AS m_id FROM \"my:typename\" m JOIN \"my:othertypename\" o ON m.id = o.main_id WHERE m.id > 0 ORDER BY m.id DESC")

[qgis-bot]

@kannes

This pull request has been tagged for the changelog.

• The description will be harvested so please provide a "nearly-ready" text for the final changelog
• If possible, add a nice illustration of the feature. Only the first one in the description will be harvested (GIF accepted as well)
• If you can, it's better to give credits to your sponsor, see below for different formats.

You can edit the description.

Format available for credits

• Funded by NAME
• Funded by URL
• Funded by NAME URL
• Sponsored by NAME
• Sponsored by URL
• Sponsored by NAME URL

Thank you!

[kannes]

I have now made the initial description in the top post changelog friendly. Here is what was in it before:

The user can enter query expressions in the filter/query dialog, but often people get confused as to why some expressions work but others don't.

Random examples:

• https://wien.rocks/@ktrinko/113052167474335397
• ILIKE not working on GeoPackage #35698

This change hopefully makes it more obvious what kind of expressions are supported. Uses the new data provider methods introduced in #58781

Compiled and tested manually with several layer types, but not all.

Screenshots

---

Old screenshots from an earlier state:

• https://github.com/user-attachments/assets/584d81aa-71a3-4dba-913a-000aa98a3638
• https://github.com/user-attachments/assets/906f6cd4-554e-499d-9df9-e0aaa2878c15
• https://github.com/user-attachments/assets/3230aaff-618c-48c4-a65a-412b43035751
• https://github.com/user-attachments/assets/d5aa9cb7-383e-42c4-8a86-bca6253ae6bd
• https://github.com/user-attachments/assets/8c111ae1-b55b-46af-a14e-0f81dc598d82
• https://github.com/user-attachments/assets/3eff6ea4-758c-4398-8726-9ef92b1efd3b

[nyalldawson]

@kannes

and links to https://docs.ogc.org/is/09-025r2/09-025r2.html#83

Let's just remove that one then

[kannes]

Woohoo! Thanks for that safety check and for merging it :)