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
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
