Hi all,
I have a problem statement where the size of ACT_HI_DETAIL has passed 800gbs in the last 6 months and we are not leveraging data from this table and wanted to find a way to bypass any kind of db insertions in ACT_HI_DETAIL table.
Approaches that i could think of -
- Implement a custom History Backend where I limit the type of entities that are persisted to the database. Looking at code, I was able to find 2 java classes which are persisted to ACT_HI_DETAIL namely -
HistoricFormPropertyEntityandHistoricDetailEventEntity - Implement a custom History Level where I can limit the
HistoryEventTypesbeing persisted to the database.
Problems that I am facing -
a. If I go with approach 1, I will be hard coding the types of java classes relating to ACT_HI_DETAIL and there is a possibility that new java class entities can be added for the table in the newer versions
b. If I go with approach 2, I am not sure which all types of HistoryEventTypes are related to ACT_HI_DETAIL
c. Is there any internal camunda use of history tables which might hinder the overall engine processes?
d. If I go with either approach 1 or 2, I want to ensure that all the other history tables are populated with default behaviour and limiting the java classes or History Event Types do not block any others.
Similar case with ACT_HI_OP_LOG but for this table, I need some of the columns to be persisted while I want to avoid the rest.
So, wanted to know which approach is better or if there is another approach other than these 2 which can be a solution to this problem.
Also, what type of data is stored in both these tables as it is not clear from the documentation, for e.g. does ACT_HI_DETAIL store only variable based data or includes process instance data etc. in order to have more clarity on what both these tables actually store.
Thank you