Should/Would you expect the cube to get updated if we change a field that is NOT one of the dimensions? And, is it only specific field types e.g. Table Lookups in the dimensions/not in the dimensions that could affect the cube being updated or not?
Currently:
If I have a TL field dimension and the value of the TL on the table changes, the cube is updated.
If I have a Text field dimension and the value of the field on the table changes, the cube is NOT updated.
If I have a field that is not in the dimensions, but something is changed on the table, the cube is not updated.
Please could you confirm - I just need to get clarity on when the cube is updated to make decisions regarding the structure of a current cube being designed/built.
For cubes, this depends on how data flows into the summary table and what the cube is actually doing with a decisional record it inherits. If configured on workflow, for example, just changing the value of any field on a record should not impact the data in the cube.
For cube summary tables, if your events are configured to read entity changes on the business data record, the summary table will pick up a change only if the associated event(s) include changes to those fields.
I suspect the differences you are seeing might have to do with what fields are captured by events, not the type of each data item (but I could be wrong on that).
Generally, fields that are a Dimension shouldnât be able to change on the record for this reason, else youâll need to queue events that listen for the changes and respond accordingly, like moving values out of bucket abc and into bucket xyz.
It could be useful to have some additional context about what triggers a summary table event, but we can also wait for someone else to weigh in on whether there are different behaviors by data item type.
No-one should be developing new instances of Nextworldâs original implementation of Cubes, they should all be using Cube Summary Tables.
I have found folks in the wider development space informally use just the word Cube to refer to what Nextworld officially refers to as a Cube Summary Table.
Assuming you have a record in a table that is specified as a Cube Summary Table data source, any record updates directly on that record will be picked up and processed. The nuance is that the change has to be directly on the data source record. This means the following changes would not be tracked by summary tables:
Table lookup related field changes
eg. The data source table may reference a Company (Directory TL record)
If the directory record for the Company specified has its Address changed, this WILL NOT trigger a summary table update.
If the record is modified to reference a different Company, this WILL trigger a summary table update.
(If the data source is a detail table) header record changes
Note I say that we will âprocessâ the record change. It will create summary table event and make a change in the cube data if any field in the record referenced by the cube definition has changed. This includes dimensions, metrics, display fields, transactional event work fields, and data source filter fields. For performance reasons, we do make a check to determine if anything relevant has changed, and do ignore the transaction if nothing related to the summary table has changed.
The typical flow is that metrics and fields referenced in the data source filters change over time. Other fields are allowed to change over time, but should be less common.
@ian.p Apologies, I am referring to a Summary table. I updated the topic title.
@jeremy.keller thanks for the input. I am going to submit a ticket on this as I am not seeing this happen when a Metric field is being updated. Will share more details on the ticket.
@jeremy.keller if a Metric is of type Logic Block Calculated will it trigger an event? I was looking into @claire.minnaarâs use case and noticed it having been set up that way.
It makes sense to me that if the metric is System Aggregated - Sum or System Aggregated - Count then a change in the field driving the metric needs to be processed, but if itâs Logic Block Calculated the value of the field associated with the metric and thus changes to that field in the data table seem arbitrary and maybe should be ignored/not processed?
The âLogic Block Calculatedâ metric âfieldâ should be mapped in the âTransactional Event Work Fieldsâ subtable (In the âTransactional Event Logic Blocksâ tab). If it is there, the system will know to track field changes for it. I can look into Clairâs setup once she submits a ticket.