Making custom Java data source Olap4j Compatible

[antimute]

Hi, I am working on a project that uses Coherence to create an aggregated cube-like object.

I would like to implement an interface to Olap4j that would allow us to access this object through standard XMLA calls, such as from Excel.

We do not need to make the entire scope of XLMA functional, our main goals are:
1. Support the current scope of where clauses and summing (max, etc is not needed)
2. Not have any fixed compile time schema definition, we would like to push this out based on system config at runtime

I read some of the documentation, but it is not very clear where I should start.
If anyone has any advice on how to get started, it would be greatly appreciated.

[Julian Hyde]

You probably need to implement quite a large portion of the MDX language and XMLA specification in order to satisfy Excel. That is quite challenging.

One approach is to start off with Mondrian’s olap4j driver, copying code from the mondrian.olap4j package, and then rip out the Mondrian dependencies.

Or maybe you could use Mondrian, and make your aggregations in Coherence implement Mondrian’s caching SPI.

Julian

On Jun 3, 2014, at 11:05 PM, antimute antimute@users.sf.net wrote:

Hi, I am working on a projet that uses Coherence to create an aggregated cube-like object.

I would like to implement an interface to Olap4j that would allow us to access this object through standard XMLA calls, such as from Excel.

We do not need to make the entire scope of XLMA functional, our main goals are:
1. Support the current scope of where clauses and summing (max, etc is not needed)
2. Not have any fixed compile time schema definition, we would like to push this out based on system config at runtime

I read some of the documentation, but it is not very clear where I should start.
If anyone has any advice on how to get started, it would be greatly appreciated.

Making custom Java data source Olap4j Compatible

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/olap4j/discussion/577988/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[antimute]

Thanks Julian.
After looking further, I am thinking of writing the contents of our custom cube into an in-memory DB like HSQLDB (http://hsqldb.org/).
The hope there is we only have to build the table and do the inserts, and then HSQLDB will take care of the rest.
It seems like Olap4j can work with any ODBC source, which means it can probably work with HSQLDB without too much intervention.

We don't want to create a true physical database, as that would increase the maintenance cost of the system, and long term access is not part of our use cases.

[Julian Hyde]

If you mean Mondrian running against an in-memory Hsqldb database, yes, that would work.

On Jun 4, 2014, at 7:13 PM, antimute antimute@users.sf.net wrote:

Thanks Julian.
After looking further, I am thinking of writing the contents of our custom cube into an in-memory DB like HSQLDB (http://hsqldb.org/).
The hope there is we only have to build the table and do the inserts, and then HSQLDB will take care of the rest.
It seems like Olap4j can work with any ODBC source, which means it can probably work with HSQLDB without too much intervention.

We don't want to create a true physical database, as that would increase the maintenance cost of the system, and long term access is not part of our use cases.

Making custom Java data source Olap4j Compatible

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/olap4j/discussion/577988/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/