Why it works so well

As with any new autonomous feature, it needs to simplify the developers world in all respects regarding the working practice it is addressing. The reality is that all approaches to date have not been comprehensive and they have not simplified development practices. ie the prevailing methods used by developers to address the complex requirements of  enterprise "time travel" continue to be used.

Our "time travel" approach is both simpler and comprehensive and importantly insulates the developer from all the inherent complexities of  handling Time in a relational system. We achieve this by elevating the development up to the current view meaning that the developer is not having to work out the schema design with respect to the periods of effect of data, the maintenance of history and audit tables, or any of the knotty issues that time brings to referential integrity over time. Quite simply, the developer is insulated from having to deal with challenges of how to manage primary key, foreign key, and unique key relationships across time. By achieving this we are genuinely providing developers with a "time travel" capability. Data entry, data corrections and data updates are achieved by setting  time coordinates and specifying the new values - the "Time Travel" capability automatically polices the integrity of the data change. In the same way, reporting is achieved by setting the required time coordinates and executing sql without the requirement for complex time clauses.

The fact that so many attempts have been made with large amounts of money spent by vendors in the past indicates that it's a useful thing to have BUT it has to be provided in such a way as to add enough value. Otherwise it the same amount of work for developers with or without the layer. Hence none of the attempts to date have resulted in widespread adoption.

If done the way we do it - then it does add enough value /insulation.