[Mondrian] RE: CurrentDateMember udf
Julian Hyde
julianhyde at speakeasy.net
Wed Aug 29 14:57:55 EDT 2007
> 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
More information about the Mondrian
mailing list