At my first post I discussed a custom constrained by, by using a Microflow as a datasource. In the example I used an Order management and created a new "Orderline". I want to go on this example and discuss how Mendix works with a phenomenon "Autocommit".
I'm going to save the new "OrderLine" with a Microflow trigger on the Form "OrderLine_NewEdit". Because it is a Microflow, it will not trigger the standard textbox validations. I have to build the validation myself. When the "OrderLine" is valid, I retrieve the "Order" from the association and calculate the total order price. Then the "OrderLine" is committed and the Form is closed.
When I debug the Microflow and look at the state of each object before and after committing the "OrderLine", something occurs. In the first step the "Order" as the "OrderLine" has the state "instantiated". The second step the "OrderLine" is committed to the database and gets the state "normal". The "Order" however has the state "autocommitted".
When the "OrderLine" is committed to the database, the association to the "Order" is also committed. In the database it isn't possible to refer to an object that doesn't exist. So Mendix inserts the "Order" and gives it the state "autocommitted". Based on this Mendix knows that cancelling the object must lead to a delete in the database, because it was't committed explicit by any logic.
- Instantiated: A new object that is only present in the application memory.
- Normal: An object that is present in the database.
- Autocommitted: An object inserted in the database by an association.
No comments:
Post a Comment