[Qgis-developer] QgsDataProvider and supportsSubsetString

[Matthias Kuhn]

Hi Chris

On Die 30 Apr 2013 22:21:37 CEST, Chris Crook wrote:
> Hi Matthias
>
> Thanks for comments.
>
>>> 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.
>
> Certainly the functionality could be placed in QgsVectorDataProvider.
> It may need some care in the relationshiop between this an the actual provider,
> In terms of managing recalculating extents, feature count, etc.  But would be nice
> to have this available in all providers and not have the user wondering why
> sometimes they can't select subsets.  (And as I just discovered, also wondering
> why they can't use a table in a join, which also requires subset string capability).
>
>  > >
>>> 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.
>
> I guess having multiple substring types for a layer could be really confusing for a user
> If that is what you are suggesting.
That was exactly what I was proposing. Provider WHERE clauses are cool 
because they're powerful and fast (executed on the backend and only 
relevant information transferred). QgsExpression WHERE clauses would be 
cool because they provide provider independence. So they both have 
their pro's and con's and I would not artificially restrict users and 
devs. Of course some good explanatory labels on the interface (and in 
the API) would make life easier.

> On the other hand if you could manage abstracting
> Into QgsExpression, that could be very cool.  Doesn't sound easy though!
>
Sounds like handling lots of special cases (e.g. recently somebody 
noticed, that OGR SQL handles string concatenation with NULL's 
differently... [1] )

> Also from a UI point of view, the QgsExpression builder dialog isn't quite right for
> a QgsExpression based subset, as it is about calculating values, not implementing a
> filter.
QgsExpression is suited for filtering as well (e.g. used in the 
attribute table). The calculated value is treated as a boolean then. 
But maybe a tweaked UI could be good for this usecase (The example 
there is pretty useless, it just shows a 1 or a 0).

[1] http://hub.qgis.org/issues/7380