Hi all, I'm trying to figure out the difference between the usage of a rollback action instead of a non-persistable entity – there is never an instance in the entire app where an object of that entity is committed… I've just finished the Learning Path 'Building an Event App Using Microflows', and in module 4.3.4, you're building entities and microflows allowing anonymous users to register for an event. 1 The entity Registration contains the attributes for all the needed data. 2 The entity Visitor will contain the final object with all data tied together. The anonymous user provides all needed data within a Registration object. The data gets validated and then a Visitor object is created (and committed), combining all data. After this, you're told to rollback the Registration object. There is no place in the entire app where a Registration object will be committed. So why not use a non-persistable entity? Is this just a matter of preference in this instance, or is there a difference I'm overlooking?
It is perfectly alright to use a non-persistable entity when the object is not supposed to commit anywhere.
But consider a situation,
Object need not to be committed but the association should be a 1-* from a non-persistable to persistable (which will not happen because the association between persistable and non-persistable should start with non-persitable entity)
In this situation , we need a persistable entity even if it is not supposed to be committed.