Now thinking in a more generic way, a JOIN would JOIN two tables and not features. In that case (we possibly might end up supporting this kind of virtual tables e.g. from python plugins) a JOIN would then return a QgsFeatureIterator wrapped in a QVariant instead of a single tuple. I am not sure how exactly such a feature would be integrated yet, and how this interacts with the current expression engine (there are a couple of shared functionalities, but also some that are different), therefore I am also not sure if this should have any implications on the current implementation. So this paragraph is just thinking out lout.
Yes, that is the most generic way. Probably a bit overkill at the moment.
That would be a join limited to certain attributes and my idea is that this would eventually be merged with the current JOIN functionality to remove duplicated work in this area.
Cool, this is certainly a very useful feature. Regards, Marco -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland [email protected] http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
