Showing posts with label association. Show all posts
Showing posts with label association. Show all posts

Tuesday, 21 October 2014

Rollback and associated objects

In a early post we've been talking about autocommitted objects in Mendix. Objects that have been automatically committed because of an association. But what do you do when then objects aren't used anymore? Actually delete or rollback the objects. 
 In the Domain Model you can set the delete behavior on associations. In the most cases the behavior is set to delete the associated objects as well. For each object Mendix will delete all objects that are associated. So with deleting one object you can delete a complete hierarchy of associated objects.

The delete behavior isn't only used for deleting objects, but also in a certain way for a rollback of an object. The setting is only used with a rollback of an instantiated object: a newly created object that haven't been committed yet. 

I've created a simple example project based on order management. The domain model is very simple with an 'Order', 'Orderline' and 'Products'. In testing the scenario the default Mendix functionality will be used, no custom created microflows. So the scenario: 
  • An 'Order' is instantiated.
  • Some 'Orderlines' are added and committed (the 'Order' will be autocommitted)
  • The 'Order' will be cancelled: executing a rollback.
No association delete behavior With association delete behavior
The 'Order' has properly been cleared, nothing in my database, but the created 'Orderlines' are still be present.
The 'Orderlines' are perfectly deleted and I have never explicit deleted. Based on the association delete behavior Mendix will delete them on a rollback.

Summarizing: Mendix works with objects that are connected with associations. Mendix doesn't know the logic hierarchy of objects that we know and program. If Mendix has to delete or rollback an object it only occurs on that instance, other objects aren't changed. The delete behavior on associations is really important to have a clean database.

Saturday, 12 October 2013

Reference selector with special constrainted by

My first post:
We all have sometimes the situation that we have to commit an object, because the retrieval of data for an reference selector will not work. The data depends on the selection of something else but the selection isn't of the same object. For example we have a form for an "Orderline" what contains the reference selector for the "Product". Here comes the tricky part, it may only be that "Product" that belongs to a "Category" selected in the "Order". The domain model can looks likes this.
In the modeler you can select the "Constraint by" property on a reference selector to let Mendix automatic constraint the data based on the associations. But in this case the "Order" is a new object and not committed to the database, so the results for the "Product" reference selector is empty. 



The reason for the missing data has to do how the constraint by function works. The constraint by function works for the first association, in this case "ODM.OrderLine_Order", and the other associations needs to be in the database, except the last one. The association "ODM.Order_Category" was not in the database and therefor the results were empty.

To solve this issue isn't to be committing the "Order" object before adding a new "OrderLine", but to use a datasource Microflow for the Reference Selector. In that Microflow you can retrieve the "Order" over association (from the memory of Mendix). Than retrieve all products that are attached to category based on the association of "ODM.Order_Category". You just don't have to retrieve the "Category" object first.