Understanding Dependent Entities in the Cascade Delete App: 

When creating a Delete-Group in the app, it’s likely that one or more dependent entities will be automatically added. 

A dependent entity is an entity with a Foreign Key attribute linked to one of the originally selected entities. For instance, in the below diagram, the 'AgenciesId' in the 'Agents' table acts as a Foreign Key connected to the 'Agencies' table. Thus, if we choose to delete entries in the 'Agencies' table, it automatically considers the 'Agents' table as a dependent and adds this to the Delete-Group. 

To simplify the Cascade Delete application logic and cater for its primary purpose of purging test data, it's assumed that the Outsystems 'protect' delete rule, has been applied to all foreign key references – meaning that any foreign key references must first be deleted before the original record. This is why it is crucial that all dependent entities are added to the Delete-Group. The app is programmed to delete the dependents in the correct order to ensure these rules are obeyed. 

For further explanation of delete rules, see the OutSystems documentation.

Rollback limitations: 

The application utilizes a Timer to avoid performance issues and timeouts. Through a self-awakening mechanism, the Timer adapts to purges surpassing 19 minutes, sidestepping the default 20-minute timeout by seamlessly restarting in a new transaction. This removes all data volume limitations. It is worth noting that the 19-minute threshold is adjustable via a Site Property and the Timer’s default timeout is adjustable in Service Centre – should you wish to adjust the logic. 

A consequence of this method involves a rollback limitation. Any data deleted in preceding Timer transactions will not be reinstated during a rollback - triggered either by an error or the manual activation of the kill switch.

For further explanation of transactions see the OutSystems documentation. 

Roles: 

• HasAdminRole : allows a user to create and edit Delete-Groups. 

• HasUserRole: allows a user to delete the data of existing Delete-Groups. 

The purpose behind having separate Admin and User roles is to enhance data safety and prevent accidental or unauthorized deletion of sensitive data. By limiting the ability to create and manage Delete-Groups to Admin users only, teams can rest assured that general users with the User role will only delete appropriate and carefully selected sets of data. This ensures a more controlled environment. 

Understanding Dependent Entities in the Cascade Delete App: 

When creating a Delete-Group in the app, it’s likely that one or more dependent entities will be automatically added. 

A dependent entity is an entity with a Foreign Key attribute linked to one of the originally selected entities. For instance, in the below diagram, the 'AgenciesId' in the 'Agents' table acts as a Foreign Key connected to the 'Agencies' table. Thus, if we choose to delete entries in the 'Agencies' table, it automatically considers the 'Agents' table as a dependent and adds this to the Delete-Group. 

To simplify the Cascade Delete application logic and cater for its primary purpose of purging test data, it's assumed that the Outsystems 'protect' delete rule, has been applied to all foreign key references – meaning that any foreign key references must first be deleted before the original record. This is why it is crucial that all dependent entities are added to the Delete-Group. The app is programmed to delete the dependents in the correct order to ensure these rules are obeyed. 

For further explanation of delete rules, see the OutSystems documentation.

Rollback limitations: 

The application utilizes a Timer to avoid performance issues and timeouts. Through a self-awakening mechanism, the Timer adapts to purges surpassing 19 minutes, sidestepping the default 20-minute timeout by seamlessly restarting in a new transaction. This removes all data volume limitations. It is worth noting that the 19-minute threshold is adjustable via a Site Property and the Timer’s default timeout is adjustable in Service Centre – should you wish to adjust the logic. 

A consequence of this method involves a rollback limitation. Any data deleted in preceding Timer transactions will not be reinstated during a rollback - triggered either by an error or the manual activation of the kill switch.

For further explanation of transactions see the OutSystems documentation. 

Roles: 

• HasAdminRole : allows a user to create and edit Delete-Groups. 

• HasUserRole: allows a user to delete the data of existing Delete-Groups. 

The purpose behind having separate Admin and User roles is to enhance data safety and prevent accidental or unauthorized deletion of sensitive data. By limiting the ability to create and manage Delete-Groups to Admin users only, teams can rest assured that general users with the User role will only delete appropriate and carefully selected sets of data. This ensures a more controlled environment.