[Mondrian] Another 2.4->3.x porting question

[Eric McDermid]

Following up to my own question...

On further review, it turns out the cached order function is no longer  
used by the application in question, so I can just scrap it.  That  
still leaves me with the customized "Key" function, but that's easy  
enough to jury-rig into a local fork.

  -- Eric

On Jun 26, 2009, at 12:39 PM, Eric McDermid wrote:

> OK, this one seems a little more arcane.
>
> One of the custom enhancements made to Mondrian in Marin's codeline  
> was the addition of a cached order function which caches a handful  
> of queries per fact table in an LRU cache to speed up pagination for  
> large dataset queries.
>
> This was done by creating CachedOrderFunDef as a derived class of  
> mondrian.olap.fun.OrderFunDef and a new CachedCalc as a derived  
> class of mondrian.rolap.AbstractListCalc.  Code attached.
>
> Registration of all this was done by getting direct reference to the  
> schema's function table, casting it to FunTableImpl, then calling  
> FunTableImpl.define(resolver) and FunTableImpl.organizeFunctions().
>
> I'm not sure that was exactly an approved technique, but it worked.   
> What's unclear to me is whether there's a more appropriate way of  
> doing it in 3.x that doesn't rely on breaking encapsulation and  
> using non-public APIs.  The CustomizedFunctionTable that Rushan  
> introduced a while back looks like it might be part of the solution,  
> but I'm not really sure of its intended usage, and in any case that  
> wouldn't get me past the calculator dependencies.
>
> -- Eric
>
>
>
>
> < 
> CachedOrderFunDef 
> .java><CachedCalc.java>_______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian