[Mondrian] RE: CurrentDateMember udf

[Julian Hyde]

> Rushan Chen wrote:
>
> So I tried your suggestions of caching a Date value in 
> RolapResult which 
> works fine to provide a constant date for the whole query. 
> However, I am 
> not sure caching the result of CurrentDateMember will work 
> because UDF 
> interface does not allow storage of any members. This cached 
> value will 
> have to be passed in to the udf, likely via the Evaluator.  The 
> Evaluator push and pop model means that any cached value will be lost 
> upon returning from an evaluate() call for a given expression 
> level. How 
> can a UDF cache its result if it does not have local storage, 
> and cannot 
> use the expression cache?
> 
> You also suggested using the cache directive in the MDX, which is 
> essentially user's way of overriding the dependency calculation for 
> caching.  I think the person who added the UDF likely has 
> more knowledge 
> as to whether the result can and should be cached, as compared to the 
> user. Would you consider selective support of the dependency 
> interface a 
> reasonable solution, given the constraint above? The way I 
> was thinking 
> is to default to the pessimistic("depend on every dimension") and 
> override the default in a few udfs like 
> CurrentDateMember/CurrentDateString.

I don't want to add a method for dependency-checking to the
UserDefinedFunction interface because of (a) backwards compatibility and (b)
dependencies are well beyond the knowledge of the typical person writing a
UDF.

This may be a case where CurrentDateMember has such complex requirements
that it needs to become a built-in function.

Alternatively, it would be OK if every UDF had state. You would need to
change UdfResolver.CalcImpl to create a new instance of the UDF each time it
is used in an expression. (Don't use clone - we can't assume that a UDF is
Cloneable - but create a new instance of the same class.) Then you would be
able to cache members inside CurrentDateMember.

Julian