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)
This check tests that if a function has been declared deprecated
with either Q_DECL_DEPRECATED or has a @deprecated Doxygen note
then it MUST have both the Q_DECL_DEPRECATD and @deprecated note.
It's important that both are used, as Q_DECL_DEPRECATED allows
throwing a warning if that method is used in code, while the
@deprecated doxygen note gives an indication to devs/PyQGIS users
of why it's deprecated and what should be used instead.
Ideally we'd also test for SIP /Deprecated/ tags, but I can't
find any reliable way to do this.
* make sip coverage test aware that there are less classes where QSci sip
headers are not available
* exclude properties from members
* fix QgsFeatureIds typedef (fixes missing signal
QgsVectorLayer.featuresDeleted and others)
* add missing notes for PyNames
* include some missing new methods in bindings
This introduces two new options to filter legend elements:
- filter by expression: a boolean expression can be set. Only symbols of
features that make the expression evaluated to true will be kept in the legend
- filter by polygon: only symbols of features that are inside the given
polygon will be part of the legend.
The polygon filtering is used in particular for a new option in the
composer legend that allows to filter out anything that is not included
in the current atlas polygon.
Not perfect, but good for a quick warning if a new class or member
has been added to the public API without Python bindings. The test
only considers the name of members, since it seems to be impossible
to test for the signature of a Python member. (So adding a new
overloaded method without bindings will still unfortunately pass).
You can avoid the test where bindings are not applicable:
- for a whole class by placing "@note not available in Python bindings"
in the class' Doxygen comments
- or by placing the @note inside a member's Doxygen comments for a
specific member
Additionally, classes which aren't included in the API docs
will not be tested.
Rationale:
- there was a lot of large objects passed by value, so potentially
there's a speed bump from this
- even for implicitly shared classes like QString/QList there's still
a (small) cost for copying the objects when there's no reason to
- it's the right thing to do!
- Main C++ core and gui classes and desktop app integration
- Support for authentication method plugins
- Does not contain any integration with service connections
The feature can be toggled individually for groups - in layer tree view context menu.
This code has been funded by Tuscany Region (Italy) - SITA (CIG: 63526840AE) and commissioned to Gis3W s.a.s.
This means that symbol selectors can be aware of the correct variable
scope and values for both populating expression builder widgets and
for symbol previews.
