nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

changeDeploymentTenantId does not set Tenant in Historic Tables

jorell

I couldn't find any info on this despite searching, apologies if this has already been addressed.

changeDeploymentTenantId in RepositoryService doent set tenant in any of the history tables which have Tenant_id_ columns (PROCINST, ACTINST). This seems like an oversight since the database ends up in an inconsistent state. Can anyone confirm?

Find more posts tagged with

Comments

martin_grofcik

Hi Jorell,

May be I do not understand the problem, but does it make sense to change the history?
When you have changed tenantId, is proper tenant id logged into history tables?

Regards
Martin

jorell

>May be I do not understand the problem, but does it make sense to change the history?
It does make sense if you are saying that deployment 'A' now has tenant 'T'. All the runtime process instances of 'A' will now have tenant 'T' but all the history tables will show blank tenant. So now, for reporting, if users of 'T' want to pull up reports on their processes, they will have lost all processes finished before the change in tenant. You will have process instances in the history table belonging to the same process definition but some will have tenant 'T' while others won't.
From my perspective a tenant is (should?) be basically an attribute of the deployment, the api also suggests this (changeDeploymentTenantId). So the historic tables have a relationship with a deployment through proc_def_id_ anyway. Having different tenant values for the same proc def values seems inconsistent to me but maybe I am misunderstanding the reasoning for this.

>When you have changed tenantId, is proper tenant id logged into history tables?
I haven't tested this out, I assumed it works but I'll test it out and report back here.

trademak

The history tables are not updated automatically. So you need to write a custom update script to make sure the history tables are also updated.

Best regards,

jorell

Yes I've written the script. I was more interested in the reasoning of excluding the history tables from the API.

trademak

Changing a tenant id is not a common step to make, because a tenant identifier typically stays the same. But of course there are cases where you would like to change the tenant id, and we support it in our runtime tables. But also changing all historic data might not be valid for all use cases where the tenant id changes. We could however add conditional logic that allows a user to define if all historic data should be changed as well. Could you create a JIRA issue for this?

Best regards,