On 16 March 2016 at 19:15, Hugo Mercier <hugo.merc...@oslandia.com> wrote: > Hi, > > Just for me to understand: why not considering improving a bit the > virtual layers ? > > There is already a support for user defined aggregate functions. Caching > of the computed aggregate is already done by the engine (I guess). And > we could add some functions to restrict the query to the selected > features of a layer or deal with relations ... > > And using something like the "query builder" found in db manager (and > inspired by mapinfo), it may ease to deal with the SQL syntax ...
I think the use case is quite different. Having aggregates in expressions is useful for things like embedding the values in composers and atlas prints, or in data defined overrides. Nyall > > On 16/03/2016 08:30, Neumann, Andreas wrote: >> Hi Paolo, >> >> Thank you for your feedback. >> >> Why do you think SQL aggregate syntax (e.g. as outlined >> at http://www.postgresql.org/docs/9.5/interactive/functions-aggregate.html) >> is a no-go? Can you explain this in detail? QGIS is much closer to a >> database then it is to a spreadsheet - in fact for most serious QGIS >> work you store your data in a SQL database. >> >> It was my impression that QGIS tries to maintain expression syntax >> compatible with SQL wherever possible. I think it would be a good thing. >> >> The question is how we can specify grouping. I'd like to see support for >> the following grouping mechanisms: >> >> >> >> * whole record set >> * given grouping field or expression >> * current selection >> * grouping based on relations (very important to my employer) - also >> our initial trigger for funding this work >> * current set of symbology rules or classes (not so important to me, >> but maybe useful to some) >> >> >> >> Andreas >> >> On 2016-03-16 08:11, Paolo Cavallini wrote: >> >>> Hi Nyall, >>> >>> Il 16/03/2016 07:17, Nyall Dawson ha scritto: >>> >>>> I'm also torn regarding the best syntax to use for aggregates within >>>> expressions. I'm unsure if the traditional SQL "group by" clauses >>>> would be a good fit within the existing QGIS expression syntax (eg >>>> "sum("some_field") group by "some_other_field"). To me it doesn't fit >>>> with the existing functional approach that the expressions take. But >>>> on the other hand, trying to implement this as functions would result >>>> in some very clumsy expressions: "aggregate('sum', "some_field", >>>> "some_other_field")" or "sum("some_field", "some_other_field") ". Has >>>> anyone got any other ideas for syntax which would be a good fit? >>> >>> Good news, thanks for sharing. >>> IMHO having a syntax that is easy to use for the average user is a >>> crucial point. I think using SQL is a no go. Why not using the >>> spreadsheet syntax? Not that I find it particularly attractive, but at >>> least everybody is more or less familiar with it. >>> All the best. >> >> >> >> >> >> >> _______________________________________________ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer