On 09/10/2015 10:15 AM, Yves Jacolin wrote: > On Thursday, September 10, 2015 9:36:31 Bernhard Ströbl wrote: >> Hi Yves, >> >> Am 10.09.2015 um 09:27 schrieb Yves Jacolin: >> [..] >>>> Apart from that if >>>> field#2 = field#1 + x >>>> then field#2 is totally redundant. You could either create a view >>>> containing this field or create a virtual field in QGIS. >>> I just simplified for the test case. This is more complicated but was not >>> useful to give such details ;) >> still this should be considered an option to show the resulting value to >> the user instead of having it in a field of its own. > Humm, I need to think a little bit on this. I am not sure that move some > logic > from the db to QGIS is always a good things. > > One of the use case which lead me to let this logic in the DB is when I use > this field in several part (for example, in a layer in QGIS and in a website, > for an export with ogr2ogr or event in several layers in QGIS). A view would be perfectly suitable for this. > > It is easier to manage one location (ie the trigger) than several (in QGIS if > we use this field in different layer). I need to check this but we are in > such > use case. > > Anyway, I agree with you in other use case that it is easier to manage this > as > a virtual field, much less trouble :) You could hide the field from the view and add a virtual field in QGIS that does the same calculation, that's probably easier than python
M. > > Y. > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
