Now the widgets factories can give a score on how good they could handle
a widget.
Additionaly, plugins can be added to choose a widget factory in function
of an external information. One of them uses a table in PostgresQL to
allow specification of the widget type and configuration.
I took the opportunity to remove a few deprecated method in relation to
this.
Now the widgets factories can give a score on how good they could handle
a widget.
Additionaly, plugins can be added to choose a widget factory in function
of an external information. One of them uses a table in PostgresQL to
allow specification of the widget type and configuration.
I took the opportunity to remove a few deprecated method in relation to
this.
When there is a layer group with several sub-layers, the group has a
"default" style and the sub-layers each have a "default" layer. QGIS
was showing two "default" styles for the sub-layers, which would be
confusing to the user and could pick the wrong legend for the
sub-layer if the user picked the wrong entry (the first one).
Had to create a static lib for wmsprovider in order to unittest it.
- show correct domain type as field type name
- correctly determine length and precision of domain types
- expose bpchar field type as 'character' to users, as postgres only
uses 'bpchar' internally and refers to bpchar as character in the
front end
- make QgsVectorFileWriter respect QTime field values and only
convert to string if required by output format
- list time types as native types for memory, postgres and OGR
providers (OGR support depends on file format)
This adds the possibility to manage data on a normalized relational
database in N:M relations. On the relation editor in a form, the tools
to add, delete, link and unlink work (also) on the linking table if a
relation is visualized as N:M relation.
Configuration is done through the fields tab where on the relation a
second relation can be chosen (if there is a suitable relation in terms
of a second relation on the linking table).
Limitations
===========
QGIS is not a database management system.
It is based on assumptions about the underlying database system. In
particular it expects
* A `ON DELETE CASCADE` or similar measure on the second relation
* Does not take care of setting the primary key when adding features.
Either users need to be instructed to set them manually or - if it's a
database derived value - the layers need to be in transaction mode
(currently only activatable through the API)
- Allow simple operators as supported by OGR (+, -, * )
- Only return a partial compilation success if expression contains
"column"="column2". Since OGR SQL performs case insensitive
comparisons, we need to double check the result using QGIS'
expressions to ensure that case matches. Add unit tests for this
to provider tests.
The postgres provider is modified so that layers with
TIN, PolyhedralSurface and Triangle geometries can be loaded.
Geometries are converted to MultiPolygons (and Polygons for Triangles).
The postgres test is completed to cover the loading of different types
of layers
Failure was caused by GDAL bug #6020, which has now been fixed
in GDAL. It turns out the values are only incorrect if the first
feature in the file has a null value, so I've rearranged the
features in the reference shapefile to avoid this.
