On 28.07.2014 13:49, Marco Hugentobler wrote: > Hi Matthias > >> Do you think it would be possible to introduce this via a JOIN syntax in >> QgsExpression? This way we would stay closer to SQL standard. > > That's a good idea, I also think JOIN syntax is better. > The return of a JOIN operation is probably a tuple, so by using that > as a QVariant, it might be possible to use something like 'JOIN( > layer_id) ON (fieldA = fieldB).$attribute'
What do you think about this notation? layer_id.attr1 + layer_id.attr2 JOIN layer_id on fieldA = fieldB The tuple would in QGIS terms be a QgsFeature I guess. 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. > > >Another possibility I was thinking of was via the relations, with the > >possibility to check some fields of a related layer as "hard joined" > >which would then be available the same way that JOINED fields are now. > > Would that basically be a join limited to certain attributes or would > the handling be totally different to the layer join mechanism? 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. Regards Matthias _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
