Just to clarify, if m.getPropertyValue took a String, would that make the API saner?

Also, it seems that the bug you've identified is caused by passing the property enum instance inside of m.getPropertyValue while it needs the hydrated property object to get a match in a map somewhere. Dunno if it should take both. Anyways. Seems to me we have to cleanup the lookups of properties. Just need to figure out if the olap4j API is misleading, or the mondrian implementation.


On Fri, Mar 7, 2014 at 9:51 AM, Paul Stoellberger <p.stoellberger@gmail.com> wrote:

 I was trying to fetch the format string of all measures in the cube, but that doesn't seem to be an easy thing to do.
The only way to get it via the Cell in a Cellset using cell Property FORMAT_STRING.

If you try to fetch it using this - directly on a cube Measure, it will be empty in mondrian:

private Format getMeasureFormat(Measure m) {
try {
String formatString = (String) m.getPropertyValue(Property.StandardCellProperty.FORMAT_STRING);

In XMLA the property should be clearly set: https://github.com/olap4j/olap4j/blob/master/src/org/olap4j/driver/xmla/XmlaOlap4jMeasure.java#L74

In mondrian I have to do this

private Format getMeasureFormat(Measure m) {
String formatString = (String) m.getPropertyValue(m.getProperties().get("FORMAT_EXP");

I don't really see a reason why this should be hidden when its there.
It seems like a standard property for measures that is even returned in the XMLA result.

From my point of view it should work like it does for XMLA - using the StandardCellProperty on a Measure member.

What do you think?


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
olap4j-devel mailing list