According to the Cube.js documentation, one can define cubes using something called Context Variables, that allows the injection of filters (such as a particular user email) when querying that cube.
I haven't tried it yet, but I want to know if this feature is compatible with preaggregations, and also if it handles empty filter cases.
For example, if I define this cube (same as the example from the docs):
cube(`OrderFacts`, {
sql: `SELECT * FROM orders WHERE ${FILTER_PARAMS.OrderFacts.date.filter('date')}`,
measures: {
count: {
type: `count`
}
},
dimensions: {
date: {
sql: `date`,
type: `time`
}
}
});
will I be able to define a preAggregation such as this?
preAggregations: {
date: {
type: `rollup`,
measureReferences: [someMeasure],
dimensionReferences: [someDimension],
timeDimensionReference: date,
granularity: `month`
}
}
and can I perform queries without a date
dimension filter? (so the sql
would end as SELECT * FROM orders WHERE;
) ?
To sum up: is there a way of injecting filters to a cube's sql
definition dynamically, but not at query time and instead at schema compile time?
I ask this because we are currently extending some cubes with information retrieved from our API, and we were overwriting the segment
field from this cubes, but due to performance issues we would prefer to overwrite the cube's sql
field (to filter unnecessary data from the start).
NOTE: We are using asyncModule
to perform the queries to our API. We also need to build different cubes (for all our clients) referencing a common table, but with a dynamic SQL that will change depending on the client.
Our desired output should be (for an Orders table and F1
, ..., Fn
client filters from our API):
N cubes that extend a base Orders
cube: OrdersC1
, OrdersC2
, ..., OrdersCn
.
Each OrdersCi
cube with a modified version of the base Orders
sql, containing its Fi
filter.
Each OrdersCi
cube with the same dimensions
, measures
and preAggregations
definitions, inherited from the base Orders
cube.
We managed to implement all that I said before, but instead of modifying the sql
field, we overwrote the segments
field.