At a member, the format string is an expression. At a cell, the format string is a value (obtained by evaluating the format string expressions of the current measure). So it's no surprise that they come out differently.

Usually the format string is a constant (say "#,###" or "(#,###);#,###") so people often don't notice this fine distinction. But members don't really have a FORMAT_STRING property. It's a cell property, and you shouldn't really be asking for it at a member. (I don't recall why it comes out of XMLA... probably to be compatible with a version of Microsoft XMLA ten years ago.)

Regarding why it's more complicated to get properties in olap4j versus Mondrian. Mondrian's list was fixed, because you are only dealing with a single version of a particular server; whereas olap4j's list could change between back-ends and versions.

Julian


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

It seems like olap4j is making things more complicated than it was in mondrian itself.
mondrian.olap.Property looks simpler than the olap4j classes.

And yeah, there are currently different approaches of looking up properties.
m.getProperties could be a simple map of String, Object - where a lookup enum can be used as well.

We could also make it more clear that there is a difference between a member property, and a cell property.
So instead of passing a Property object we could make it a  getPropertyValue( <MemberProperty | CellProperty | DataTypeProperty> property )  depending on the object its executed on.
There would be less confusion on how and with what method / property object one can look up the value.
Additionally provide a getPropertyValue(String) for other / arbitrary properties that are not in the standard.


However the issue is more about mondrian olap4j not populating the FORMAT_STRING property of a Measure object in the first place, while a XmlaOlap4jMeasure does it.
Since SSAS seems to return the formatstring apparently when Measures are fetched, we should do the same in mondrian.
One could argue that a format string is as much of a vital method as fetching the aggregator or datatype of a measure, so we could add it directly as method in org.olap4j.metadata.Measure


-Paul



On Mar 7, 2014, at 4:10 PM, Luc Boudreau <lucboudreau@gmail.com> wrote:

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.

Luc


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

 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 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?

-Paul



------------------------------------------------------------------------------
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.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
olap4j-devel mailing list
olap4j-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/olap4j-devel



------------------------------------------------------------------------------
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.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________
olap4j-devel mailing list
olap4j-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/olap4j-devel