I wanted to add the test for gpkg subsetstring even if
it was not bugged, while testing that, I hit an assert
in Qt core that pointed me to double unlocked locks.
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)
