In our data warehouse, hierarchies can change in two distinct ways:<br><ol><li>Hierarchy members can be added or deleted.</li><li>Fact values associated with an existing hierarchy member can change.<br></li></ol>The DataSouceChangeListener.isHierarchyChanged() allows Mondrian to effectively handle addition or deletion of hierarchy members, but Mondrian does not (that I am aware of) flush cell regions associated with a changed hierarchy. Our DataSourceChangeListener now uses the CacheControl API to clear affected cell regions as a side-effect of the isHierarchyChanged() call when a hierarchy has changed.<br>
<br>In outline, we flush cell regions associated with a particular hierarchy as follows:<br><ol><li>Iterate through hierarchy.getRolapSchema().getCubes() to populate a map<Cube, RolapCubeMember> with (cube, hierarchy.getAllMember()), ignoring virtual cubes and cubes that don't support the hierarchy. </li>
<li>Iterate over the map and call cacheControl.flush(cacheControl.createCrossjoinRegion(cacheControl.createMemberRegion(allMember, true), cacheControl.createMeasuresRegion(cube))).</li></ol>Basing the memberRegion on the allMember is probably not correct in the general case but it works for the volatile dimensions in our warehouse. Note that the createMemberRegion method's Member parameter must actually be an instance of RolapCubeMember; if it isn't, the subsequent call to the flush(CellRegion) method will throw an exception. We make sure we've got a RolapCubeMember by iterating through cube.getHierarchies() to find the hierarchy we're interested in and returning its allMember.<br>
<br>This appears to be working well, but an "is..." method with a fairly major side-effect has a bit of a code smell.<br><br>Questions:<br>Is there a
better place than isHierarchyChanged to hook in the cell region flush?<br>Have I overlooked something significant in my use of the CacheControl API?<br>
<br>
Jon<br>