Re: [Olap4j-devel] MeasureGroups & olap4j on mondrian 4

[Paul S. <p.s...@gm...>]

Sounds fine to me.
Do we have a list of stuff we want to work on in olap4j 2.0? Except the things mentioned in those older emails.
Shall we keep track of them somewhere?
What about the maven file structure / splitting up of the source trees?
We have in saiku 1 repo with several projects that all "belong together", this way its easier to track changes that affect several parts at the same time.
So we could do the same with olap4j, having various submodules / projects for olap4j-xmla + olap4j-xmlaserver + olap4j-tck + olap4j

I would propose having the xmla driver in a separate project folder as well. It is a separate artifact and I think it should be clearly separated as such

-Paul



On Dec 11, 2012, at 9:12 PM, Luc Boudreau wrote:

> On the subject of which olap4j depend on which Mondrian.
> 
> We will need to make only one release on the olap4j 1.X codebase, because of the bug in Locale's LCIDs. That release can be done before the release of Mondrian 4.0 and can be the official dependency.
> 
> Right now, olap4j master depends on Mondrian 4.0. The only changes required were related to SSAS naming and some metadata tests who expect less information than what is provided. I'd rather the olap4j master branch remain built against Mondrian 4.0. It already works and all tests should be passing by the end of the week (I'm currently working on it).
> 
> I propose this.
> 
> To work on olap4j 2.0, we can create a branch in GitHub. Let's call its artifacts olap4j-2.0.0-SNAPSHOT. Because olap4j's TCK depends on Mondrian (the good ol' circular dependency problem) we might need to create a temporary branch for Mondrian 4.0. That Mondrian branch would contain only the few changes necessary to test the olap4j implementation, and nothing else. If we keep it that way we can merge everything back easily as soon as olap4j 2.0 is out of the door. The only risk to doing this is if Mondrian requires many core changes which would prevent us from testing olap4j correctly. Can any of us think of potential changes which would make it difficult to manage and would force us to consistently merge back and forth?
> 
> Luc
> 
> 
> 
> 
> On Wed, Oct 3, 2012 at 7:15 PM, Julian Hyde <jh...@pe...> wrote:
> On Oct 3, 2012, at 8:00 AM, Paul Stoellberger <p.s...@gm...> wrote:
> 
>> So there will be some new exciting stuff in Mondrian 4. One of them is measure groups.
>> 
>> When I use the olap4j xmla driver on SSAS I get already information about MEASURE_FOLDER and MEASURE_GROUP in the response.
>> Right now we don't have anything to handle that correctly in olap4j yet.
> 
> I agree that olap4j needs to provide more metadata, both for mondrian-4 and for users of other OLAP engines such as SSAS.
> 
> Because olap4j is a standard API, we can't make breaking changes (e.g. add new methods) lightly. We should make changes in major revisions of olap4j, and these should be infrequent -- at least 18 months apart.
> 
> I propose that olap4j version 2.0 support the whole current XMLA model, as described in the SSAS 2012 documentation: http://msdn.microsoft.com/en-us/library/ms126079.aspx.
> 
> In addition to all entities and attributes, we should include all enumerations. For example, for the MDSCHEMA_DIMENSIONS data set, we need enumerations to support columns DIMENSION_TYPE, DIMENSION_UNIQUE_SETTINGS (the MDDIMENSIONS_MEMBER_KEY_UNIQUE bit value), CUBE_SOURCE (values 1 CUBE and 2 DIMENSION) and DIMENSION_VISIBILITY (values 1 visible, 2 not visible).
> 
> Lastly, and obviously, methods and enum constants should have javadoc.
> 
> I know this is quite a task. But I would like to cover the whole XMLA API before we declare olap4j-2 beta, rather than doing things incrementally.
> 
>> I would propose we change the Measure discovery and add another layer.
>> 
>> cube.getMeasureGroups().get(0).getMeasures()
> 
> I agree, there should still be a way to get the measures of a cube directly (cube.getMeasures()). Most people are not interested in which measures occur in which fact table.
> 
>> The display folders could be either a measure property or we file the measures in their folders directly:
>> measure.getDisplayFolder()
>> vs.
>> cube.getMeasureGroups().get(0).getDisplayFolders().get(0).getMeasures()
> 
> We should do whatever XMLA does. I didn't think that display folders were a formalized concept in XMLA & SSAS; I may be wrong.
> 
>> I'm not sure if there is always a measuregroup. In case there isn't we can create a default one. This would also allow us to handle mondrian 3, that doesn't have this concept yet.
> 
> Agreed.
> 
>> Now before we decide how to implement this, we need to discuss how we handle this in the codebase.
>> The mondrian olap4j driver is now part of the mondrian codebase, which I don't like very much. The driver is just a thin wrapper around mondrian so I think it can live somewhere else so we can change the API without affecting mondrian directly.
> 
> olap4j is mondrian's primary API. It definitely needs to be in the code base.
> 
> Maybe you are uncomfortable that it is difficult to find & refactor all olap4j drivers that exist. Get used to that feeling! Since this is a standard API, the changes we make to olap4j have to be slow and predictable (not agile!).
> 
>> The second point is olap4j itself. Do we plan to move to github?
> 
> I would like to move it to github. Now seems to be a good time. Any volunteers to do this?
> 
> After the move to github is complete, I would also like to move to a maven file structure. And we can have discussions about whether olap4j-xmlaserver, olap4j-xmla and olap4j-tck should be in the same source tree in the same repo, or in different source tress  in the same repo, or in different repos.
> 
>> If so, we could just create a new branch of olap4j that is based on mondrian 4.
> 
> I agree. In fact olap4j-1.x could become a branch, and olap4j-2.0 would be developed on master.
> 
>> Julian, you mentioned we will change the API for olap4j 2.0 - would you say this is part of this refactoring?
>> How do you guys want to proceed with this?
>> Although mondrian 4 will take some time to be released, the concept of measure groups can already be utilized by SSAS users so I would like to implement this rather sooner than later.
> 
> As I said earlier, we can't make breaking changes to olap4j-1.x. We can only make changes to olap4j-2.
> 
> I would consider making mondrian-4 depend on olap4j-2 -- but only if others are prepared to step up and help deliver olap4j-2 on mondrian-4's schedule. Clearly olap4j-2 would need to be production before mondrian-4 goes production.
> 
> Julian
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> olap4j-devel mailing list
> ola...@li...
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel
> 
>