Hi, I'd like to put back on the table the static/dynamic function discussion we had one month ago in a thread titled "Dynamic function concept: a new interface?"
Let me summarize the discussion here. The issue with functions is that they never get encoded down in native filters (sql and the like) and thus having a function around normally slows down filter evaluation quite a bit. However it's a common case to call a function to do some sort of static evaluation, where the result does not really depend on any attribute, and thus the result would just be the same every time: in this case the function can be replaced by the equivalent literal and just fully encoded down in native filtering language. Now, what are the dynamic, what are the static cases: - a function call that has any feature attribute among the arguments is dynamic, its results will change depending on the current feature. Fully dynamic - a function like "env" can return different values over time, but during a single filtering session its results are stable so it can be optimized out - a function like "random" should never be optimized out, as its results change over time no matter what So what I'd need here is a way to mark functions that are not going to provide a stable result during the query evaluation _even_ if they are not given any attribute as an argument. Databases have a similar classification, see how postgres classifies functions in immutable, stable and volatile: http://www.postgresql.org/docs/8.0/static/sql-createfunction.html A function like now() is stable (tried it out, always return the same value within the evaluation), a function like random() is volatile. In the previous thread I suggested we call this a DynamicFunction, with the following interface: /** * A function whose return value may vary during a data access operation * even if the function is not given feature property values and the context * of the function is not changed. A function whose return values may change * during different data access operations or as a result of a change in their * context/configuration are not considered dynamic (enough). * Dynamic functions will not be optimized out as static values by the * filter/expression simplifier before the data access takes place */ interface DynamicFunction { } The beauty of this is that I'd have to mark just one function with it... random()! If you prefer we could call that VolatileFunction, that would match Postgres naming. In the previous thread multiple people observed they would have rather have had the opposite concept, StableFunction, a function that always returns the same value provided it does not have PropertyName among its attributes. Which it's possible, but would required to go an modify every single function with it. Possible, but longer and error prone (rather easy to forget to mark a stable function as such). However it would match the postgres assumption, in the docs they say "At most one choice may be specified. If none of these appear, VOLATILE is the default assumption." Soo... what say you? VolatileFunction is a matter of a little patch, probably no proposal needed, StableFunction would require a massive hunt down and mark, probably worth a proposal just because of the size of the change (I'd have to put my hands pretty much everywhere functions are declared). Cheers Andrea -- Ing. Andrea Aime Technical Lead 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 ----------------------------------------------------- ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
