[Mondrian] Name resolution

[Julian Hyde]

Just a heads up. I'm rewriting mondrian's name-resolution code. (How mondrian looks up a hierarchy when you write '[Time].[Weekly]', or how it finds a calculated member when you write '[Store].[USA].[CA + WA]'. This code is in SchemaReader.lookupCompound and Util.lookupCompound.)

On the main branch (which will be mondrian-3.3 release), the new code will only be enabled if you enable SSAS-compatible naming. If you do not set mondrian.olap.SsasCompatibleNaming=true, you will continue to use the old code.

When I've completed the work, I will merge to the lagunitas branch (which will be the mondrian-4.0 release).

As a side-effect, I expect to fix http://jira.pentaho.com/browse/MONDRIAN-960, but maybe not all the corner cases.

To be honest, I am doing this change to make mondrian-4 development easier. I didn't want to make the change, but it turns out that there are number of flaws in our name resolution, and these are blocking me as I try to get the test suite running under mondrian-4. It was easier to make the change on the main branch, where the test suite is passing, than on the lagunitas branch, where about 50% of the tests are failing. When it is working on the main branch, I will integrate to lagunitas.

The current approach tries to resolve names, in full, using several scopes (query scope, cube scope, schema scope), and it applies access control as it goes. I believe that it wastes effort, in that each scope will invoke its ancestor scopes (which previously failed) before looking up in its own scope.

The new approach will resolve names in parallel, using several resolvers (one each for query, cube, schema) to resolve each segment in a multi-part name. This should work better when dealing with objects that cross scopes (e.g. calculated member [Store].[USA].[CA + WA] is defined in a cube, but its parent [Store].[USA] is read from the database). The new approach doesn't apply access control until it has resolved an object.

Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110819/88bb6e65/attachment-0001.html