Mondrian 2 assertion failed: Segment.java

[emofine]

Here's the actual code on which the assertion failed (in Segment.java, line 837):
Object get(Object[] keys) {
Util.assertTrue(keys.length == axes.length);
This did not happen in earlier versions of Mondrian.
Does anyone have any idea why this is happening -- besides the obvious, that is, keys.length != axes.length :) ?

[emofine]

This is a followup.
The original MDX query that caused this problem was
select {[Measures].[INST], [Measures].[AVAL], [Measures].[ASGN], [Measures].[ADMN], [Measures].[RSVD], [Measures].[AGNG], [Measures].[INTM], [Measures].[PO], [Measures].[OFFC], [Measures].[LRN], [Measures].[TEST], [Measures].[TLDN], [Measures].[E911], [Measures].[SDT], [Measures].[DNPL]} ON COLUMNS, Hierarchize(Union(Union(Union(Union(Union(Union({[Location].[CT]}, [Location].[CT].Children), [Location].[CT].[GREENWICH].Children), [Location].[CT].[GREENWICH].[203].Children), [Location].[CT].[GREENWICH].[203].[422].Children), [Location].[CT].[GREENWICH].[203].[422].[0].Children), [Location].[CT].[GREENWICH].[203].[422].[0].[GREENWICH].Children)) ON ROWS
from [Utilization_Report]
where ([Time].[200505], [RC State].[All RC States].[CT], [WC State].[All WC States].[CT])
When I changed the slicer to the following (removed the [CT] from WC State), the problem went away:
where ([Time].[200505], [RC State].[All RC States].[CT], [WC State].[All WC States])
I am not sure of what is going on here, but it seems as if Mondrian is allowing an invalid query to make it through. I don't know. Any ideas, please?

[jhyde]

It's clearly a bug, and no obvious cause comes to mind, but there are some factors which might make a bug more likely to show up:
Are there virtual cubes involved?
Might this be a concurrency problem. In other words, does this query show up when you are running multiple queries?
I notice references to a bunch the same geographical location in several dimensions. Do these dimensions share the same underlying tables?

[emofine]

Julian, thanks for the quick response. To answer your questions:
1. No virtual cubes are involed.
2. It shows up consistently in single, sequentially invoked queries (no concurrency)
3. The dimensions do share the same underlying table.
The schema (with names changed to protect the guilty) for the cube looks like this:
<Table name="kb_table"/>
<Dimension name="Location" foreignKey="foreign_key">
<Hierarchy hasAll="false" primaryKey="foreign_key" visible="false">
<Table name="map_table"/>
<Level name="LEVEL_1" column="col1"/>
<Level name="LEVEL_2" column="col2"/>
<Level name="LEVEL_3" column="col3"/>
<Level name="LEVEL_4" column="col4"/>
<Level name="LEVEL_5" column="col5"/>
<Level name="LEVEL_6" column="col6"/>
<Level name="LEVEL_7" column="col7"/>
<Level name="LEVEL_8" column="col8"/>
</Hierarchy>
</Dimension>
<Dimension name="Dim_1" foreignKey="foreign_key" >
<Hierarchy hasAll="true" primaryKey="foreign_key">
<Table name="map_table"/>
<Level name="Dim_1" column="col1" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
<Dimension name="Dim_2" foreignKey="foreign_key">
<Hierarchy hasAll="true" primaryKey="foreign_key">
<Table name="map_table"/>
<Level name="Dim_2" column="col2" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
... omitted dimensions 3 - 7 for brevity ...
<Dimension name="Dim_8" foreignKey="foreign_key">
<Hierarchy hasAll="true" primaryKey="foreign_key">
<Table name="map_table"/>
<Level name="Dim_8" column="col8" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
There is no dimension associated with LEVEL_5. I hope this helps...

[jhyde]

I bet the multiple uses of the same table are confusing some poor piece of code. I'll see if I can reproduce. It may take me a day or two. Watch this space.

[emofine]

As a matter of interest, I am getting this exception on a whole lot of different queries now, for example
select {[Time].[200505],[Time].[200506]} on columns,
{[RC State].Members} on rows
from [Utilization_Report]
where ([Measures].[INST])
but this works fine:
select {[Time].[200505],[Time].[200506]} on columns,
{[RC State].[CT]} on rows
from [Utilization_Report]
where ([Measures].[INST])
Omitting the rows axis also generates the exception:
select {[Time].[200505],[Time].[200506]} on columns
from [Utilization_Report]
where ([Measures].[INST])
My understanding is that this should be a valid MDX query. I wish I would get the full schema to you somewhow, but I regrettably cannot post it on the forum. Suffice it to say that Mondrian is being used in a large and critically important OLAP environment (DB size = many hundreds of GB and millions of rows) and success is critical (and time is very short - as usual).
This application would be a very good proving ground for Mondrian, and I think it would be beneficial to Mondrian for you and I to work together more closely. I could then share more details about the project, and share additional features that we are adding to it. What do you think about that?

[rehdie_easyplex]

I have the same problem. I've tried to reproduce it using the Foodmart-Schema delivered with Mondrian 2.0 RC 1 (not the official release).
How to reproduce the problem:
1. modify the FoodMart.xml:
add a new Dimension to the Cube Sales:
<Dimension name="Cities" foreignKey="customer_id">
<Hierarchy hasAll="true" allMemberName="All Cities" primaryKey="customer_id">
<Table name="customer"/>
<Level name="City" column="city" uniqueMembers="false"/>
</Hierarchy>
</Dimension>
2. perform the following query:
select {[Time].[1997]} ON COLUMNS,
Hierarchize(Union({[Customers].[All Customers]}, [Customers].[All Customers].Children)) ON ROWS
from [Sales]
where ([Cities].[All Cities].[Burbank], [Measures].[Store Sales])
3. expand Node USA
4. expand Node CA
=> now you have the assertion in mondrian.rolap.agg.Segment
Ok, the Dimension "Cities" does not really makes sense, but in our application we have the following hierarchies:
Product Category
Customer Owner
Customer
Product
and
Customer Owner
Product Category
Customer
Product
which is required for our reports. Both hierarchies refer to the same table using the same foreign key, which seems to be the root-cause for the problem.
I hope this helps...

[bennychow]

Julian
I think I know where the bug is. It occures when you have two dimensions with levels mapped to the same table-column.
The problem is that RolapStar::mapCubeToMapLevelToColumn will contain a cube which has two levels mapped to the same RolapStar::Column. This occurs because RolapState::Table::lookupColumnByExpression re-uses the column when it finds the same physical table-column mapping for a level. (This is probably a bug.)
What ends up happening is that if a CellRequest constrains only one level (of the two that are mapped to the same column), it will contain a bitKey that picks up an Aggregation that contains both levels.
I hope this helps.
Benny

[emofine]

Julian,
Have you had any luck with this bug?

[jhyde]

Sorry, I haven't had chance to look at it yet.

[avix]

Any news on this? We ran into this bug too ...

[jhyde]

I still have not had chance to look at this. I've logged bug 1433418 [
https://sourceforge.net/tracker/index.php?func=detail&aid=1433418&group_id=35302&atid=414613
]

[goncha]

This bug occurs when tow dimension in a cube map to a single table and a query involes both these tow dimension.

[jhyde]

Fixed in change 5851.
I'm assuming that Benny's testcase is representative of this bug. That is, it only occurs when the same column, joined via the same join-path, is constrained via two different dimensions.
Everyone who reported this bug, please check out the fix in the next day or so and make sure this problem is solved.