Carol App Installation: allow to materialize the staging tables applying the crosswalk and adding new fields that belongs to the Carol App
Description
PRDE - Story default text according to the team DoR (Definition of Ready)
01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM):
02 - PROBLEM (WHAT'S THE CURRENT PROBLEM SCENARIO OR PAIN TO BE RESOLVED?):
Today we have Carol Apps that can’t migrate to Unified Tenants, and for these tenants we should have a way to allow to install the Carol App applying the defined crosswalk and adding new fields the Carol App is defining.
We also need to apply a default behavior when installing a Carol App avoiding to break existing Carol Apps on customer’s tenant.
03 - GOAL (DESCRIBE THE PROPOSED SOLUTION):
The installation of a Carol App ({{/api/v1/tenantApps/
{carolAppId}/install}}) should consider a default process of update the staging table instead of apply a new schema dropping existing columns.
The rules we should follow:
- Add a new validation if the staging table does not exists, create it (without consider the parameter
forceMaterializeRestricted
. - If the parameter
force
(forceMaterializeRestricted
):- True:
- Only add new columns the Carol App has additionally to the fields the customer’s staging table have defined.
- Do not remove existing columns that are not part of the snapshot that is updating the existing staging.
- Update the crosswalk (primary key) of the staging table as defined on the Carol App snapshot for the specified staging table. This is a replace action (not append).
- False:
- Skip the staging table materialization (as today).
- True:
- In case the field type of the carol app tenant and customer tenant is different, it should register a warning message on Carol App installation task’s log informing:
- The connector “A“ and staging table “Y” has the field name “X” with the type “string” and the app has it defined as “integer”. The schema change was applied to add any new field available on the Carol App for this staging table.
- As today we don’t allow staging table to change the cluster and partitioning.
- Please check
CAPL-4596: PX07 - As tenant admin I should install a Carol App without impacting global ...Canceledfor more refence.
Flow:
04 - WHO CAN USE THIS FEATURE (USER ROLES): Tenant Admin
06 - ACCEPTANCE CRITERIA:
- Follow rules defined above (The rules we should follow🙂.
Related issues:
- This card will be cancelled (replaced) by this one here ( PRDE-3125 Done ).
- This issue has the goal to allow the Carol Admin to define Global Connectors that will not materialize the staging tables.
This issue was automatically transitioned to WAITING DEPLOY, as its linked QA regression issue has just reached WAITING DEPLOY status (PR was just merged into master branch in Github).
Ok, thank you.
This issue was automatically transitioned to TESTED & MERGED, as its PR was just merged into develop branch in Github. PR Approved by glaucioscheibel,wsneto.
Flag removed
I’m removing the flag that was initially blocked by https://totvslabs.atlassian.net/browse/CAPL-5410 . After a discussion on our backlog review (24-01-31), it was agreeded that we’re going to move with this card to production even though the other (CAPL-5410) is not ready yet. This is because we have benefits coming from this implementation that justifies the deployment ASAP. What we should have caution is to NOT create RESTRICTED ConnectorModels until we deploy the https://totvslabs.atlassian.net/browse/CAPL-5410 c/c @Geny Isam Hamud Herrera @Robson Thanael Poffo @Bruno Furtado @MARCOS STUMPF
Flag added
BlockedBy: https://totvslabs.atlassian.net/browse/CAPL-5410
Testing scenario regarding this thread https://totvscarol.slack.com/archives/C20SEQ867/p1706555245979589?thread_ts=1706539291.492159&cid=C20SEQ867
Connector
xpto
STGproduct
on Dev TenantDEVgijoe
Table Schema:
Install Carol App from Dev Tenant
Devemacao
Table Schema (connector
xpto
stgproduct
) from Dev TenantDevemacao
The connector model
xpto
is linked to connectorxpto
as RESTRICTEDLogs from carol app installation task
No materialization occurs as expected
Novo teste no cenário A3 que apresentou falha contemplando as considerações abaixo.
How to test atualizados com as considerações.
Evidências
Creating | Updating a RESTRICTED Connector Model
Linking the RESTRICTED Connector Model with connector on Dev tenant
Added new field (
newColumn3
) to STGproduct
on DEV tenantCreated new Carol App version (1.0.6)
New field NOT materialized (
newColumn3
) on UNIF tenant after App Update (from 1.0.5 to 1.0.6)? 🟢New field NOT materialized (
newColumn3
) on CUSTOMER tenant after App Update (from 1.0.4 to 1.0.6) 🟢Questions marker:
Should Unified apply the same concept of non-materialization that the customer receives?
There may be changes between schemas in the CUSTOMER and UNIFIED tenants if the installation of any version is skipped.
For example, in version 1.0.5 installed in the UNIFIED tenant, there were schema changes that were applied due to the fact that the model connector was of the NORMAL type. The CUSTOMER tenant did not install this version and in the meantime there was a new version 1.0.6 released and installed in the UNIFIED one with the RESTRICTED connector model for this same connector.
In this case, when installing version 1.0.6 in the CUSTOMER tenant, it will not receive the changes applied in version 1.0.5 previously installed in the UNIFIED one (eg. PK change). Can we have side effects and is this expected behavior?
Bom dia pessoal voltado aos testes do , em alinhamento com , segue o retorno da primeira analise feita frente ao findings. cc
• Connector nlp RESTRICTED connector foi encontrado, porem o mesmo nao foi configurado com o connector da tenant customer, justificando do por que materializou a staging as it is.
• Espera-se que a tenant unified sempre tenha a materializacao realizada? Nao localizei esse AC no card, sendo assim, creio que seja um topico de outro card
Sent by Slack - back-end - Douglas Coimbra Lopes
Testes concluídos do time de produto.
Sandbox: https://gijoecomandos.qarol.ai/carol-org/admin/tenants
Resumo:
Evidências
First Installation
Connector materialization
Staging materialization
Data Model materialization
Updating App with changes on STG
usertable
| DMmdmuser
schemasChanges:
Added
newColumn
to STG & DMRemoved
Groups
from STG & DMSTG schema before App Update on Customer
STG schema after App Update on Customer (🟢 for
groups
/ 🟢 fornewColumn
)DM schema
Creating | Updating a RESTRICTED Connector Model
Added new field (
newRestrict
) to STGusertable
on DEV tenantCreated new Carol App version
New field materialized (
newRestrict
) on UNIF tenant after App Update 🟢New field materialized (
newRestrict
) on CUSTOMER tenant after App Update 🔴PK (
login
) forusertable
| PK (id
) forproduct
before update on Dev TenantAdded new field (
company
) to existing PK onusertable
STG intonlp
(RESTRICTED
) for DEV TenantAdded new field (
newColumn
) to existing PK onproduct
STG intoxpto
connector (NORMAL
) for DEV TenantCreated a new Carol App version on DEV Tenant
Updated the new App version on UNIF Tenant
New PK (
login
,company
) materialized onusertable
STG into UNIF Tenant 🟢New PK (
id
,newColumn
) materialized onproduct
STG into UNIF Tenant 🟢New PK (
login
,company
) materialized onusertable
STG into CUSTOMER Tenant 🟢New PK (
id
,newColumn
) materialized onproduct
STG into CUSTOMER Tenant 🟢XPTO
connector model becomeRESTRICTED
Creating a new connector model with the same name of an already existent (
XPTO
-RESTRICTED
) 🟢XPTO
connector model becomeNORMAL
Creating a new connector model with the same name of an already existent (
XPTO
-NORMAL
) 🟢The connector
XPTO
already exists on DEV tenantDEVemacao
Creating a new connector
XPTO
on a DEV tenantDEVgijoe
🟢RESTRICTED
connectorxpto
snapshot
field dropped from STGproduct
Install
forceApp
withforceMaterializeRestricted
= TRUE on UNIFIED and CUSTOMER tenantsMaterialized STG
product
with schema changes: new PK (id
,barcode
) and new field (newColumn
) on UNIFIED tenant 🟢Materialized STG
product
with schema changes: new PK (id
,barcode
) and new field field (newColumn
) on CUSTOMER tenant 🟢NORMAL
connectornlp
Install
forceApp
withforceMaterializeRestricted
= TRUE on UNIFIED and CUSTOMER tenantsMaterialized STG
usertable
with schema changes: new PK (login
,company
) and new field (newColumn
) on UNIFIED tenant 🟢Materialized STG
usertable
with schema changes: new PK (login
,company
) and new field (newColumn
) on CUSTOMER tenant 🟢@MARCOS STUMPF ,
@Jonathan Willian Moraes , @André Pereira de Oliveira , @Glaucio Scheibel , @wilson.souza
This issue was planned to be delivered until 2024-02-12. You can check that by consulting the issue in the Due Date field.
Dates already planned for this issue: 2024-01-23, 2024-02-12
If External Issue Link field is filled, customer was also informed on JIRA TOTVS.
Regression validated.
Card validated by QA team.
Github user wsneto has just approved a PR (added as Shard Assignee in this Jira issue).
feat: https://totvslabs.atlassian.net/browse/CAPL-5136#icft=CAPL-5136 add rule when update staging schema - connector model restricted
This issue was automatically transitioned to QA REVIEW, as its PR was just approved in Github.
This issue was automatically transitioned to REVIEW, as its PR (not DRAFT and not WIP) was just created in Github.
feat: https://totvslabs.atlassian.net/browse/CAPL-5136#icft=CAPL-5136 add rule when update staging schema - connector model restricted
@MARCOS STUMPF ,
@Geny Isam Hamud Herrera ,
This issue was planned to be delivered until 2024-01-22. You can check that by consulting the issue in the Due Date field.
Dates already planned for this issue: 2024-01-22
If External Issue Link field is filled, customer was also informed on JIRA TOTVS.