[Qgis-developer] QgsDataProvider and supportsSubsetString

[Matthias Kuhn]

Hi Chris,

On 30.04.2013 08:33, Chris Crook wrote:
> Hi All
>
> As we are looking at API tidy ups (I understand), would there be any support for providing a bit more granularity in supportsSubsetString.  At the moment this is a simple boolean, and the GUI offers a SQL based subset string builder.
>
> However not all providers naturally use SQL based strings.  I'm interested in adding subset capability to the delimited text provider, whichi I've done using QgsExpression as the basis for subsets.  This works very well except that the GUI isn't an expression builder.  I think there may be similar issues with the WFS provider.
>
> What I am proposing is something more like an enum QgsDataProvider::SubsetStringType, which could then be interrogated by the properties dialog to select the appropriate query builder dialog.
The best thing would be to define this as flags, where a provider can
say, which types of subset it supports. Support for QgsExpression could
actually be directly implemented in the base class
(QgsVectorDataProvider) and not in a specific provider, as it can be
applied to any provider.

>
> Logically this would supplant the supportsSubsetString boolean which could be deprecated, replaced with
>
> virtual QgsDataProvider::SubsetStringType QgsDataProvider::subsetStringType(){ return NoSubsetString; }
I think the supportsSubsetString would then have to be replaced by
supportedSubsetTypes(), which returns a set of flags which tell, which
types a certain provider supports.
Your method would then most likely become currentStubsetType(), which
tells the currently enabled subset method.

>
> Other types could be SqlSubsetString, ExpressionSubsetString, ...?
I was always wondering if it would be possible to translate a
QgsExpression (or at least a subset) to native provider SQL. Like a
database abstraction layer. This would allow to develop plugins
independent to data providers while keeping the possibility to let
database servers do the job they're best at.


>
> Thoughts anyone?
>
> Thanks
> Chris
>

Matthias