No-history mode for Master Index
If you are not interested in the transaction history, a lot of database space could be saved for a Master Index project if the BLOB field which captures the delta for each transaction is not saved in the transaction table.
You can live without this delta if you are not doing and unmerge and not trying to recreate transaction objects from the transaction history.
To achieve a no-history mode for Master Index, as MIDM by default shows the transaction history tab, we need to hide that. Second as we are not interested in saving the delta we should not compute the delta or save that on the table. The first one will save some CPU time and second one will improve the database performance and the overall performance.
To prevent calculation of the delta, we should stop all the TransactionObject.setDelta(TransactionLog.getLogs("Enterprise", eo)) calls in the TransactionMgrImpl.java. We should do this for all public APIs in TransactionMgrImpl.
The transaction record update in the transaction table is two step. The first update writes everything in the transaction table except the delta and the second step is to update the delta for the same transaction record. This is done in individual createTransactionObjectDB method of the particular DBAdapter implementation of the project (could be Oracle, MySQL or SQLServer).
This is done in two steps as the writing back the BLOB to the database requires additional processing. To optimize the performance in no-history mode we must check such mode and stop the delta to be saved to the database.
However the idea of simply deleting the BLOB fields from the database could result in set of serious problems as several methods in TransactionMgrImpl are public and all the basic Master Index functionality invokes these APIs. Whenever such APIs are invoked to set delta or recreate a transaction object from transaction log, there will be severe exceptions as those APIs will try to access the BLOB which does not exist any more.
Conclusion: No-history can be introduced as a project property but has to be carefully handled as described above in the various level of implementation, to prevent functionality failure, optimization, performance and scalability.
