[Qgis-developer] QgsDataProvider and supportsSubsetString

[Chris Crook]

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.  On the other hand if you could manage abstracting
Into QgsExpression, that could be very cool.  Doesn't sound easy though!

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.

This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.