Hi Andrea; I just lurked last during the last conversation. The idea is a sensible one; a couple questions. Do we need to be able to check this out when making a function (Is it information that should be available as part of FunctionFactory interface; or as part of FunctionName?)
Or are you content to just have the marker interface VolitileFunction so you can check the result at runtime. I also note that marker interfaces have fallen a bit out of use in favour of annotations. Not sure we would care. So +1 on the idea; and one question about making the information discoverable prior to creation. Jody On 28/01/2011, at 8:59 PM, Andrea Aime wrote: > 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 ------------------------------------------------------------------------------ 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
