Just like classic compilers, like C or C++, and interpreters, like VB can be optimized for running code this could also be done with the Mendix microflow runtime engine. I see many microflow you use lists, not because that make the logic clear, but they commit faster.
The Mendix interpreter could implement that behaviour internally to take the work out of hand of the user. My idea is that all commits are internally stored in lists per type and at the end of the microflow, when the transaction is commited, all data is committed per list. Should also work in Sub-microflows.
The idea makes sense. There are some things to take into consideration:
– The list for a type needs to be flushed not just at the end of the transaction (not the end of the microflow anyway), but also whenever a retrieve is done that would be affected. Retrieves for the same entity are obvious, but any retrieves that have an xPath restriction that touches the entity would be affected as well.
– This would only work if no commit events are configured (you could theoretically still trigger any before commit events at the moment when putting the object in the internal list)
– A developer may suddenly be hit with a performance loss when adding a simple retrieve to an existing application because it may trigger a flush of one of these internal lists.