Oracle fails if you try to run more than the 'processes' parameter in init.ora, typically 150. The throughput of Oracle and other databases will probably reduce long before you get to their limit.

If a query exceeds the limit, you will get an error such as:

Mondrian result limit exceeded: Mondrian Error: Size of CrossJoin result (53,463) exceeded limit (50,000)

Number of members to be read exceeded limit 50,000

and Mondrian throws a mondrian.olap.ResourceLimitExceededException. See also limit properties.

When storing collections of cell values in memory, Mondrian has to choose between a sparse and a dense representation, based upon the possible and actual number of values. The density is defined by the formula

density = actual / possible

Mondrian uses a sparse representation if

(possible - countThreshold) * densityThreshold > actual

For example, at the default values (countThreshold = 1000 and densityThreshold = 0.5), Mondrian use a dense representation for

• (1000 possible, 0 actual), or
• (2000 possible, 500 actual), or
• (3000 possible, 1000 actual).

Any fewer actual values, or any more possible values, and Mondrian will use a sparse representation.

This allows objects dependent on Mondrian properties to react (that is, reload), when a given property changes via, say,

 MondrianProperties.instance().populate(null);

or

MondrianProperties.instance().QueryLimit.set(50);

Used for the LocalizingDynamicSchemaProcessor; see Internationalization for more details.

If a query exceeds the limit, mondrian throws a mondrian.olap.QueryTimeoutExceptiony, resulting in an error such as:

Query timeout of 10 seconds reached

See also limit properties.

If a query exceeds the limit, mondrian throws a mondrian.olap.ResourceLimitExceededException, resulting in an error such as:

Number of iterations exceeded limit of 100

See also limit properties.

Property determines if elements of dimension (levels, hierarchies, members) need to be prefixed with dimension name in MDX query. For example when the property is true, the following queries will error out. The same queries will work when this property is set to false.

• select {[M]} on 0 from sales
• select {[USA]} on 0 from sales
• select {[USA].[CA].[Santa Monica]} on 0 from sales

When the property is set to true, any query where elements are prefixed with dimension name as below will work

• select {[Gender].[F]} on 0 from sales
• select {[Customers].[Santa Monica]} on 0 from sales

Please note that this property does not govern the behaviour where in

[Gender].[M]

is resolved into a fully qualified

[Gender].[All Gender].[M]

In a scenario where the schema is very large and dimensions have large number of members a MDX query that has a invalid member in it will cause mondrian to to go through all the dimensions, levels, hierarchies, members and properties trying to resolve the element name. This behaviour consumes considerable time and resources on the server. Setting this property to true will make it fail fast in a scenario where it is desirable

For example, Gender doesn't join with [Warehouse Sales] measure.

With mondrian.olap.agg.IgnoreMeasureForNonJoiningDimension=true

Warehouse Sales gets eliminated and is ignored in the aggregate value

SUM({Product.members * Gender.members})

[Store Sales] + [Warehouse Sales] = 7,913,333.82

With mondrian.olap.agg.IgnoreMeasureForNonJoiningDimension=false

Warehouse Sales is part of the aggregate value.

SUM({Product.members * Gender.members})

[Store Sales] + [Warehouse Sales] = 9,290,730.03

On a report where Gender M, F and All members exist a user will see a large aggregated value compared to the aggregated value that can be arrived at by suming up values against Gender M and F. This can be confusing to the user. This feature can be used to eliminate such a situation.

See the connect string specification for more details.

Any value besides 0 or -1 gives deterministic behavior. The default value is 1234: most users should use this. Setting the seed to a different value can increase coverage, and therefore may uncover new bugs.

If you set the value to 0, the system will generate its own pseudo-random seed.

If you set the value to -1, Mondrian uses the next seed from an internal random-number generator. This is a little more deterministic than setting the value to 0.

Possible values are the following:

• "NONE": no warning (default)
• "ANY": any dialect
• "ACCESS"
• "DERBY"
• "LUCIDDB"
• "MYSQL"
• ... and any Dialect enum in SqlPattern.Dialect

Specific tests can overwrite the default setting. The priority between test setting and property file setting is:

Settings besides "NONE" in mondrian.properties file < Any setting in the test < "ANY"

If true, then Mondrian uses aggregate tables. This property is queried prior to each aggregate query so that changing the value of this property dynamically (not just at startup) is meaningful.

Aggregates can be read from the database using the mondrian.rolap. aggregates.Read property but will not be used unless this property is set to true.

If set to true, Mondrian intelligently optimizes certain predicates.

If set to false, then predicates are optimized only when all the members of a dimension are included.

Example:

For the in MDX query which selects all but one member of 1997 quarter:

select {[Time].[1997].[Q1],[Time].[1997].[Q2],[Time].[1997].[Q3]} on 0 from sales predicate optimization would result in sql that retrives all 4 quarters, instead of just 3. The fourth quarter is cached along with others for future use:

...where`time_by_day`.`the_year` = 1997 group by `time_by_day`.`the_year`, `time_by_day`.`quarter`...

(note the where in clause involving quarters is missing)

when predicate optimization is disabled, Mondrian would retrive no more data than specified by the query, In the above case it would retrive only data for first 3 quarters:

...`time_by_day`.`the_year` = 1997 and `time_by_day`.`quarter` in ('Q1', 'Q2', 'Q3') group by `time_by_day`.`the_year`, `time_by_day`.`quarter`...

If set to true, then Mondrian scans the database for aggregate tables. Unless mondrian.rolap. aggregates.Use is set to true, the aggregates found will not be used.

If true, Mondrian uses the aggregate table with the smallest volume (number of rows multiplied by number of columns); if false, Mondrian uses the aggregate table with the fewest rows.

Can be either a resource in the Mondrian jar or a URL. See aggregate table rules for details.

Normally, this property is not set by a user.

If true, RolapStar does not cache aggregate data from one query to the next: the cache is cleared after each query.

With the cache disabled, an expression like:

Rank([Product]. CurrentMember,
     Order([Product].MEMBERS, [Measures].[Unit Sales]))

would perform many redundant sorts.

The default is true, that is, use a cache. If you wish to use the member cache control aspects of mondrian.olap.CacheControl you must set this property to false.

If true, Mondrian generates SQL strings are generated in the log or output in pretty-print mode, formatted for ease of reading.

This value may be variant among database products and their runtime settings. Oracle, for example, gives the error "ORA-01795: maximum number of expressions in a list is 1000".

Recommended values:

• Oracle: 1,000
• DB2: 2,500
• Other: 10,000

Currently grouping sets will be used only against Oracle, DB2 and Teradata.

Must have the value "Mondrian".

The URL of the JDBC database where the data is stored. You must specify either DataSource or Jdbc.

The name of a data source loaded via JNDI. The name must be a valid JNDI name, and the object referenced must implement the javax.sql.DataSource interface. You must specify either DataSource or Jdbc.

Comma-separated list of JDBC driver classes, for example,

JdbcDrivers=sun.jdbc.odbc.JdbcOdbcDriver,oracle.jdbc.OracleDriver

The name of the user to log on to the JDBC database. (If your JDBC driver allows you to specify the user name in the JDBC URL, you don't need to set this property.)

The name of the password to log on to the JDBC database. (If your JDBC driver allows you to specify the password in the JDBC URL, you don't need to set this property.)

The URL of the catalog, an XML file which describes the schema: cubes, hierarchies, and so forth. For example,

Catalog=file:demo/FoodMart.xml

Catalogs are described in the Schema Guide. See also CatalogContent.

An XML string representing the schema: cubes, hierarchies, and so forth. For example,

CatalogContent=<Schema name="MySchema"><Cube name="Cube1"> ... </Schema>

Catalogs are described in the Schema Guide. See also Catalog.

Not used. If, in future, Mondrian supports multiple catalogs, this property will specify which catalog to use. See also Catalog.

Tells Mondrian whether to add a layer of connection pooling.

If the value "true" is specified, or no value is specified, Mondrian assumes that:

• connections created via the Jdbc property are not pooled, and therefore need to be pooled;
• connections created via the DataSource are already pooled.

If the value "false" is specified, Mondrian does not apply connection-pooling to any connection.

The name of the role to adopt for access-control purposes. If not specified, the connection uses a role which has access to every object in the schema.

This property can contain multiple role names separated by commas. If so, queries in the connection execute with the sum of the privileges of all of the rules; the effect is the same as running under a union role, defined using the <Union> element in the schema file.

If a role name contains a comma, escape the comma using an extra comma. For example, a connection created with

Role='Pacific region manager,Europe,, Middle East and Africa manager'

will execute with the combined privileges of the roles "Pacific region manager", and "Europe, Middle East and Africa manager".

Any property whose name begins with "jdbc." will be added to the JDBC connection properties, after removing this prefix. This allows you to specify connection properties without a URL.

For example, given the properties

jdbc.Timeout=50; jdbc.CacheSize=1m

Mondrian will create a JDBC connection using the properties {Timeout="50", CacheSize="1m"}.

Allows mondrian to work with dynamically changing schema. If this property is set to true and schema content has changed (previous checksum doesn't equal with current), schema would be reloaded. The default is false.

Could be used in combination with DynamicSchemaProcessor property.

Controls whether a new connection use a schema from the schema cache. If true, the default, a connection shares a schema definition (and hence also a cache of aggregate data retrieved by previous queries) with other connections which have a textually identical schema definition.

If false, the connection has a private schema definition and cache.

The name of a class which is called at runtime in order to modify the schema content. The class must implement the mondrian.spi.DynamicSchemaProcessor interface. For example,

DynamicSchemaProcessor = mondrian.i18n.LocalizingDynamicSchemaProcessor

uses the builtin schema processor class mondrian.i18n.LocalizingDynamicSchemaProcessor to replace variables in the schema file, according to resource files and the current locale (see the Locale property).

The requested Locale for the current session. The locale determines the formatting of numbers and date/time values, and Mondrian's error messages.

Example values are "en" (English), "en_US" (United States English), "hu" (Hungarian). If Locale is not specified, then the name of system's default will be used, as per java.util.Locale#getDefault().