You could check by doing a database retrieve of the reservation entity with xpath constraint like [id = $Reservation/id]. before doing the commit. If both objects are the same the object was already changed in the database. (use the debugger to check all variables)
My guess is the object that the onChange microflow receives is the object which is changed but not yet committed. If there is a overlap you could try to call a rollback action for the reservation object.
The only way to do a manual "rollback" is to have some kind of audit trail on the reservation object.
Thanks for your input. Based on your suggestion, I'm trying to see if I can use the Community Commons menberHasChanged() or getOriginalValueAsString() Java methods as the first calls to my Calendar OnChange Microflow in hopes of being able to grab the origianl Start or End dates of a Calendar Event that is changing. However, I seem to be struggling with this because the member that I'm looking at is a DateTime rather than a string. Trying to use the toString to convert the member property using something like toString($Reservation/Start) doesn't seem to work. It almost seems as I need a getOriginalValueAsDateTime() method ... that doesn't exist.
But, I hope that this may be an approach to recover the original Start or End DateTime in the Calendar OnChange Microflow as a means of allowing me to recover after an "illegal" drag and drop of a Calendar event.
Follow Up Note:
Use of the Community Commons getOriginalValueAsString() does indeed allow me to capture the original Start and End of a Calendar Event and can be effectively used in the "On Change" calendar microflow. If the newly changed time slot fails tests for suitability (for example, overlaps an existing calendar event if we don't allow overlaps) the original Start and End can be replaced to restore the original event prior to the change.
The original problems that I encountered earlier when trying to use the getOriginalValueAsString() method were due to my misunderstanding of what the member field was expecting: It is expecting the string representing the column name: e.g. 'End' rather than a string of the value of that column name such as toString($Event/End) which was what I originally attempted.
It is possible that use of the AuditTrail module may also be useful, but I have not yet explored that.
Maybe I am missing something, but it seems to me that in your microflow, you could use a Rollback action to rollback the calendar appointment in case there is a conflict. This is one of the out of the box actions, so you shouldn't need to use Community Commons. Also, I can confirm what Stephan said - when calendar events are changed via drag and drop, the object that is passed to the onChange microflow has not been committed - so doing a Rollback on that object will reset the values to what they originally were.
Hope that helps,
Thanks for taking the time to make that confirmation. I had originally tried to use the built-in Rollback and have now gone back to look at my original attempts once again. I now believe, however, that the problem that I thought I had when I tried to use the rollback was actually a flaw in my own thinking that resulted in microflow logic that never actually got me to the Rollback activity.
Thanks for encouraging me to look at the more straightforward approach again,