After testing with simple entities setup on Mx version 7.23.3 and 8.0.0 (beta). You could also try debugging.
In the above figure I have created an entity without committing and then created another entity (committed and associated to the uncommitted entity). This results in the auto-committed object (Temporarily stored in the database).
Maybe see if your current Mendix version is changing these variable states from auto-committed to normal; if they are remaining as auto-committed even after explicitly committing – these can potentially go missing. – maybe consider upgrading to the latest Mendix version.
When debugging further with the auto committed objects. I thought I might be able to replicate auto-committed objects going missing, but these versions don't seem to reflect this issue of deleting objects even after explicitly committing.
Auto-committed objects can still get deleted though.
– but I logged out before saving the object.
and the object was no longer stored in the DB.
if I created a new object and saved I don't get the auto-commit logs. And when debugging, the entity state changes from instantiated to normal.
Start looking at referenced objects and their delete behaviour. Because if some object has a reference to PO with the delete behaviour to also delete the PO when it gets deleted…
But indeed autocommits just sucks and no one could ever explain to me WHY these objects need to be removed from the database. Yes when I have autocommits the developer has made a mistake and great that you help him by autocommitting. But why delete those objects?
Inside the creation microflow, including a commit on the create activity of the PO object should prevent object from going into that auto-commit state (missing). – this definitely sorted out our issue with missing objects.
If you are not committing to DB on creation this is most likely setting the object to auto-commited. – as soon as the user logs out the object will be auto-deleted!
I hope this helps, otherwise if the PO's still go missing I would suggest implementing an XML/schema export to create backup of the PO in a JSON/XML file so that it can be stored and imported again if it goes missing.
Next to the delete behaviour, also check if you commit objects from within a dataview where you also show PO's through a reference. This can also cause this annoying issue.
I have had an issue with this where I have found that even though the commit flag has been set on the Creation Action, if you are setting values on this newly created entity and you use a value that is another entity which is an autocommit entity, then you can lose this normal object if the user logs out.
My issue was the above scenario and opening a page for edit with the autocommitted entity. The page had a simple Save and Cancel. Even if the user clicked Save and then logged out of the system, the normal entity was lost.