Most engines in ONE create or update transactions; forecast engines create forecasts, replenishment engines generate order forecasts, transportation engines generate movements.

The sticking point with the output of transactions is the performance question – using Model-Based Action insert/updates vs. Prepared Statements. Model-Based insert/updates carry a lot of flexibility in business logic BUT come at a significant performance cost.

Another sticking point with transactional data is how to deal with transactions from previous runs.

Delete Previous Results

Deletes are difficult in Oracle. There is a huge contention issue if running deletes from multiple threads across multiple nodes. Deletes – even without multi-threading – are difficult due to undo logs, cascade deletes, indexes, etc.

If a Delete is done, an engine option must exist to NOT do the delete. The delete instead is done by a SQLDef engine run BEFORE the engine. This allows the delete to be done in a single thread – often executed within a Stored Proc to allow for controlled transaction sizes.

Null/Zero/Cancel Previous Results

Marking transactional data in such a way that it is no longer used is faster than delete, but this depends on how the system uses the transactional data.

Merge Previous Results

If the engine knows the transactions from previous runs, then it might be possible to update those results. Any new data may need to create new transactions. Any data that couldn’t be updated would need to be deleted or nulled out.