Incremental Refresh
Incremental refresh is called through the Application API. It is important to note that all table names and field names are those from the DirectQuery local schema.
final TableUpdateDetail tableUpdateDetail =
TableUpdateDetail.create(
"SALES",
ChangeType.ADD_ROWS,
ConditionFactory.equal("DATE", LocalDate.of(2022, 4, 16)));
app.refresh(ChangeDescription.create(List.of(tableUpdateDetail)));
Here some change examples with their change description.
Multi table add rows
In this case, we have added some new sales for the seller google.
We have also added a new product.
sales has a many-to-one relationship with product.
Table sales changes
| date | product | seller | quantity |
|---|---|---|---|
| 2024-01-01 | P1 | microsoft | 20 |
| 2024-01-01 | P2 | amazon | 30 |
| 2024-01-01 | P2 | amazon | 20 |
| 2024-01-01 | P1 | 20 | |
| 2024-01-01 | P2 | 30 | |
| 2024-01-01 | P3 | 20 |
Table products changes
| date | product | quantity |
|---|---|---|
| 2024-01-01 | P1 | 10 |
| 2024-01-01 | P2 | 20 |
| 2024-01-01 | P3 | 30.0 |
Change description
| Table Update Detail | sales | products |
|---|---|---|
| Change type | ADD_ROWS | ADD_ROWS |
| Change Scope | sales.seller = 'google' | product.product = 'P3' |
final List<TableUpdateDetail> updateDetails =
List.of(
TableUpdateDetail.create(
"SALES", ChangeType.ADD_ROWS, ConditionFactory.equal("SELLER", "google")),
TableUpdateDetail.create(
"PRODUCTS", ChangeType.ADD_ROWS, ConditionFactory.equal("PRODUCT", "P3")));
app.refresh(ChangeDescription.create(updateDetails));
Multi table add rows using an unknown condition
In this case, we have added new rows in sales table.
All these new sales has a new seller which has been added in users table.
sales has a many-to-one relationship with users.
Table sales changes
| date | product | seller | quantity |
|---|---|---|---|
| 2024-01-01 | P1 | microsoft | 20 |
| 2024-01-01 | P2 | amazon | 30 |
| 2024-01-01 | P2 | amazon | 20 |
| 2024-01-02 | P1 | 20 | |
| 2024-01-02 | P2 | alibaba | 30 |
| 2024-01-02 | P3 | ibm | 20 |
Table users changes
| id | warehouse |
|---|---|
| microsoft | nyo-1 |
| amazon | chi-1 |
| tor-1 | |
| alibaba | bei-1 |
| ibm | par-1 |
This change can be expressed with this description which could be cumbersome to build because of the IN condition.
Change description
| Table Update Detail | sales | users |
|---|---|---|
| Change type | ADD_ROWS | ADD_ROWS |
| Change Scope | sales.date = '2024-01-02' | users.id in ('google', 'alibaba','ibm') |
Here we managed to resolve a cumbersome condition looking at the data, but sometimes it is not possible to come up with a convenient condition.
In this case you can use the unknown condition.
Change description with an unknown condition
| Table Update Detail | sales | users |
|---|---|---|
| Change type | ADD_ROWS | ADD_ROWS |
| Change Scope | sales.date = '2024-01-02' | Unknown condition |
This solution could have adverse consequences.
If you have defined a factless hierarchy on user table, the missing link with the fact table forbid us to use the sales
table scope.
Connector will full refresh on this hierarchy stream.
final List<TableUpdateDetail> updateDetails =
List.of(
TableUpdateDetail.create(
"SALES",
ChangeType.ADD_ROWS,
ConditionFactory.equal("DATE", LocalDate.of(2024, 1, 2))),
TableUpdateDetail.create("PRODUCTS", ChangeType.ADD_ROWS, ConditionFactory.unknown()));
app.refresh(ChangeDescription.create(updateDetails));