Question

Can auto commits delete objects that are actually commited before?

4

tldr: yes they can, under certain situations. We are currently investigating some issues regarding missing data and what we see is that the data that is missing is also mentioned as removed autocommited objects. Whether they are the same i cannot tell because the log message only mentions that the object types are the same. But it frightens me, because the objects that are disappearing are actually committed at some point. e.g. some other objects exists and they can only exist when the removed object is in state B which it can only get by a commit. It was always my believe that the objects were only marked as auto commited (and thus removed) if they are never commited before, but the issues makes me doubt my believes. Is there someone else who can shed some light on this or share their experience with auto commited objects being removed? Edit I did some more testing and found out the following: The auto commit removal process respects delete behaviour but does not trigger events on the deleted object. Thus you cannot set an event handler on the object that is removed, but you can set an event listener on the associated object to check the delete. Also you can prevent the deletion of autocommited objects by setting delete behviour to “only delete if not associated with”. My quick and dirty solution for now is to create an extra “PreventDelete” object and when my Case reaches a state in which i do not want it to be deleted anymore i associate it with the PreventDelete entity. This should ‘solve’ my problem untill i find out why the object is marked as auto commited in the first place. Edit2: Instead of using the only delete if, we used a before delete event handler on the PreventDelete entity and set the delete behaviour to On delete of Case also delete PreventDelete entity. This allows us to throw down some logging in cases when the PreventDeleteEntity is removed. For that to work you need to add a before delete event to the PreventDelete entity and set it to Throw error if the before delete event returns false. Then you let your before delete mf either always return false, or you base it on some logic so that you can still manually remove the items if necessary. Edit3: After some testing, today indeed showed that auto commits can delete objects even though they are explicitly commited. Logging on the before delete shows that the state of my object is different from my default state. Because the state is only set in my setState Microflow this is something that should not occur imo, i will file a bug report and get back you to see what happens. Edit4: In order to make my ticket complete i decided to build a test project to make it reproducable and after a while i found out the quirck that was in my model. Something that you could describe as ‘expected’ behaviour yet it seems very strange, so im gonna take it up with Mendix anyway because im very curious about what they think (disclaimer: This is how i think it works based on my test results, not (yet) on actual insights from Mendix) . - It starts with causing the autocommit, this is pretty clear, you commit an entity that references to an entity that is not commited ‘yet’, nor is it committed later on in the same microflow. This will result in marking your entity as autocommited. In my case this microflow ends up in a form in which i can edit my order, but also the client which is linked to the order. When saving the order directly it seems to detect that the order is commited explicitly and thus the autocommit tag is removed. But when saving the client we do something additionally that triggers a perma save of the autocommit tag. - saving the client also updates all related orders in the database. Because the order is autocommited it is also retrieved from the database and thus commited (semi-explicitly) afterwards. However this semi-explicitly saving of the order seems to break the autocommit functionality because when you now continue with saving your order in the normal way and then log out it is removed. My theory is that the auto commit function somehow determines that the retrieve was not supposed to retrieve the order in the first place (because it was auto commited at that point) thus marking it as an object that is supposed to be deleted, no matter how many times you commit it afterwards.

asked 2019-11-22

Pieter van de Braak

4 answers

Tim v Steenbergen · Answer 1 · 2019-11-22

All in favor of removing autocommit, please upvote this ide, posted by a very experienced and well-respected Mendix Expert https://forum.mendix.com/link/ideas/650https://forum.mendix.com/link/ideas/650.

Yes, the idea is planned, but it has been for over 18 months now.

Fabian Recktenwald · Answer 2 · 2019-11-22

Hi Pieter,

I’ve also encountered some unexpected behaviour with autocommit. Technically, if you commit an object it is no longer autocommited and should also not be deleted by the autocommit behaviour. But I’ve also encountered cases where this did not seem to work like that. However I could never fully trace the wrong behaviour and in the end it was only fixed by avoiding the autocommit.

My thinking on this is: whenever you get some autocommit message consider this a bug and don’t expect to get any well defined behaviour.

regards, Fabian

Ronald Catersels · Answer 3 · 2019-11-22

I have had multiple discussions on this subject and I will share the latest response from Andrej Koelewijn on this subject:

Maybe an example will make this clear: suppose you have a form where users can create orders with order lines. User starts by filling out partial order (not committted), then creates a new order line and saves/commits this to the database.
At this point the order does not yet exist in the database. But mendix cant save the orderline without an order in the database, as it needs to create the association info in the db. This is solved by temporarily auto-commiting the partial (unfinished) order. This creates a temporary order in the database, but one which does not necessarily comply with all the validations (as it was never officially committed).
Now, if at this point the user changes his mind, and abandons the order, the order has never been officially committed by the user (just the line). Mendix interprets this as an indication that the user doesn't want the order with lines saved to the database and will remove the partial (autocommitted) order from the database at the end of the user session.
To avoid this, the developer should either 1) create a microflow in the order line save button which officially commits both the orderline and the order (and make sure both validate), or 2) not save the order line, but save the order + lines in one go when the complete order has been entered.
So the key to understanding this behavior is this: the reason auto-committed objects are deleted is that they just consist of partial data which has never been validated. If we leave them in the database, you will end up with incorrect data.

So indeed the delete behaviour does indeed remove committed objects. My opinion is that removing the object also leads to incorrect data in a lot of the time. A sollution might be to add another checkbox to the commit acction to also commit any changed referenced object at the same time. That would solve any modeler mistake because you forgot to save some referenced object along the way.

Regards,

Ronald

Nikel Kruizinga · Answer 4 · 2019-11-22

I am not able to provide much help here other than saying that I have run into bugs around auto-commit behaviour as well. But that was when working with Mendix 6, not 7.

I assume you have explained your reasoning on why you are sure your “state B” hypothesis is correct to a number of rubber duckies?