<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.)<div><br></div><div>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.</div><div><br></div><div>When I've completed the work, I will merge to the lagunitas branch (which will be the mondrian-4.0 release).</div><div><br></div><div>As a side-effect, I expect to fix&nbsp;<a href="http://jira.pentaho.com/browse/MONDRIAN-960">http://jira.pentaho.com/browse/MONDRIAN-960</a>, but maybe not all the corner cases.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Julian</div></body></html>