[Mondrian] Architectural notes: Mondrian and unique names

Anton Nikitin cybernelly at gmail.com
Tue May 29 08:25:21 EDT 2007


Good day!

I would like to share some of my thoughts about Mondrian architecture which
appeared during 4-years of product usage and development. 

We are using Mondrian engine in our software product. We are very interested
in reusing base MDX engine logic, but at the same time we would like to have
an option to extend and to override some basic behavior, but not to lose the
ability to merge our code with latest Mondrian sources.

I do understand that there is a lot of work related to business features,
stability, performance, etc. But maybe some of my ideas will be also useful
to other Pentaho/Mondrian customers...

Actually my thoughts are about OLAP elements (metadata) unique names and all
related logic such as creation, resolution, etc.

The following points in current architecture (Mondrian 2.3.2.8944) seem to
me not very well-designed.

1. The format of unique names is currently similar to MSAS 2000. It is
hardcoded at the level of base classes (mondrian.olap package) and could not
be effectively changed without changing some of these classes. At the same
time there can be situations when one needs more flexible behavior for
assigning unique names (for example, SSAS 2005 has several different
mechanisms for assigning member unique names depending on the structure of
the hierarchy: it affects performance). There also can be other reasons why
one wants to redefine this logic (for example, someone could want to have
hierarchy unique names as in SSAS 2005).

2. The name resolution logic is distributed across multiple classes. There
are many lookupXXX() methods in different classes.

3. Lookup methods usage is rather intricate. Sometimes they accept unique
names, sometimes simple names, sometimes exploded unique names (!);
sometimes they have options to throw an exception in case of failure,
sometimes not, etc.

My suggestion is abstracting/encapsulating unique-names-related logic into
set of classes/interfaces and providing corresponding extension points. It
seems that something similar was initially intended: there is
mondrian.olap.NameResolver interface that was never (!) used.

- Introducing interface UniqueName, creating base implementation which will
also contain all this explode/implode/quote stuff from mondrian.olap.Util.
- Introducing interface for unique names creation
- Introducing interface for resolving unique names into metadata objects
- Ensuring that there is no code in mondrian.olap package (which doesn't
belong to base unique names implementation) which relies on some format of
unique names: only usage of interfaces is allowed.

Actually, the absence of such flexibility is currently the only reason why
we cannot use mondrian.olap.*Base classes for our metadata and need to make
some changes in core MDX Engine classes. It really makes merging with latest
Mondrian code rather complicated. 

I saw some related point in roadmap (3.10), maybe it should be extended. 

I would very appreciate any comments about this. 

Kind regards,
Anton Nikitin







More information about the Mondrian mailing list