search

mysticfall / pivot4j

Pivot4J provides a common API for OLAP servers which can be used to build an analytical service frontend with pivot style GUI.
Other
128 stars 101 forks source link

Level / measure selection doesn't work when other axis is empty. #93

Closed klaudiusz223 closed 11 years ago

klaudiusz223 commented 11 years ago

To reproduce incorrect behavior:

  1. Select cube (e.g. Sales)
  2. Drag level "Store Country" from dimension "Store" and drop on rows ( it renders only dimension "Store" instead dimension and level "Store Country" - that's issue no. 1)
  3. Drag level "Product Family" from dimension "Product" and also drop on rows - it exchanges "Store" with "Product" instead crossjoin them - that's issue no. 2 (most important)
  4. Open "Config hierarchy member" for "Product" - there are no selected members (to the right side) - that's issue no. 3 (eventually it's the same problem like in no. 1)
mysticfall commented 11 years ago

It's an unfortunate side effect of applying #79 and it only happens when the model is not property configured (i.e. missing an axis).

It not only happens with levels, but you can reproduce it with measures too. So first, I'll change the title appropriately.

The problem is caused by the fact that you have no idea what members or levels are present in an axis before you have a query result.

It's not a problem with Olap4J's query model (i.e. Saiku) as it keeps all user selections in memory. However, such models have disadvantages when it comes to support user MDX as there's no clear way to merge or switch between query models.

On the other hand, JPivot builds the query model for not user's selection, but for MDX parse tree, which enables it to simultaneously support grid view and MDX editor, however it cannot track selections without query result so causing problems such as this.

Before #79, we had a valid model even when both the axes are empty as it places an empty sets there.

I believe it could be somehow dealt with implementing #92 in particular way, of which I'll explain the possible approach there.

mysticfall commented 11 years ago

I believe we need to do it before 0.8 release, even without considering #92, as now it's rather confusing for users.

At the very least, if there's no easy way to do it, we should inform users they need to fill all the axes before they could select other levels or members.

mysticfall commented 11 years ago

Applied sort of a middle-of-the-road workaround for this problem. Namely, use empty sets like before fixing #79, for all cases except when the XML/A Mondrian driver is used, and for that case try to guess what members are present from the parse tree.

This guess work will not work correctly for many corner cases, and should be considered as an workaround till #92 is properly implemented.

However, such a failure in resolving members will not critically hinder usability, and it won't happen for most common cases. So, I'll just mark it as closed for now.