Yep, I also was confused about the name "Dynamic". "Static" or "Stable" sounds better since the result of such a function is a constant for the query.
About the environment map. I think this map must be frozen during the query, otherwise results are unpredictable and not repeatable in case of problems. Cheers Chritian Quoting Justin Deoliveira <[email protected]>: > I think the idea is good but perhaps the interface needs a bit of tweaking. > It might make more sense go reverse the notion and come up with a > "StableFunction" because it seems that a function that returns a static > value (like env) would seem to be the monitory. Perhaps I am wrong though. > > Also it would seem that a function implementing the interface simply to > return false would be equivalent to not implementing the interface at all? > So perhaps we could keep the interface strictly a marker interface? > > 2c. > > -Justin > > On Wed, Dec 8, 2010 at 3:17 PM, Andrea Aime > <[email protected]>wrote: > >> Hi, >> for a number of reasons I'd like to be able to analyze a filter and >> optimize out functions when possible. >> >> The main driver behind this is that none of the stores support functions >> natively (they could, but they not) and thus the filters are not fully >> encoded >> down to the database, with much performance detriment. >> >> A typical case is the enviroment function, as soon as it's used the filters >> using it stop being sent to the database, which is of course a performance >> killer. It would be nice to recognize that the function is not using any >> feature attribute, so it can be evaluated at the beginning of the data >> access and optimized out into a literal. >> >> Now, generically speaking the "optimize out" test is just analyzing >> the function arguments and see if there is any usage of the feature >> attributes: if there is none, the function is static, right? >> Err... almost. >> A function such as "random" is not going to return the same value >> twice: that's a purely dynamic function. >> >> A function such as "env" is going to return the same value during >> all the data access, well, at least unless something else changes >> the enviroment map _during_ the data access. >> >> What I would like to have is some sort of DynamicFunction marker >> interface that tells me if a function is dynamic or not. Maybe a >> bit more than just a marker: >> >> interface DynamicFunction { >> /** >> * Returns true if a function is going to return the same >> * value during a data access operation unless >> * someone changes its configuration >> */ >> boolean requestStable(); >> } >> >> Random would implement that interface and return false, >> env would implement it and return true. >> Stores, in particular JDBC ones, would use a visitor >> that optimizes out all functions not using attribute values >> that are not dynamic, or that are dynamic but request stable. >> >> This would make the usage of env functions better, >> and would solve an issue reported by Mike P. recently >> that the renderer is optimizing out a random() call into >> the symbolizers be optimized out and return the same >> value all over the render. >> >> Opinions? >> >> Cheers >> Andrea >> >> ----------------------------------------------------- >> Ing. Andrea Aime >> Senior Software Engineer >> >> GeoSolutions S.A.S. >> Via Poggio alle Viti 1187 >> 55054 Massarosa (LU) >> Italy >> >> phone: +39 0584962313 >> fax: +39 0584962313 >> >> http://www.geo-solutions.it >> http://geo-solutions.blogspot.com/ >> http://www.linkedin.com/in/andreaaime >> http://twitter.com/geowolf >> >> ----------------------------------------------------- >> >> >> ------------------------------------------------------------------------------ >> This SF Dev2Dev email is sponsored by: >> >> WikiLeaks The End of the Free Internet >> http://p.sf.net/sfu/therealnews-com >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
