Rethink validation approach

Current design of methods that alter data is as follows, there are three methods:

• validateUpdate - Validates whether the update can be done up to predefined constraints
• _update - Proceeds with update without validation step. It's intentionally marked as private so it's not considered for normal use
• update - This one internally calls validateUpdate and if that goes fine _update is invoked.

Still in external API's we like to use validateUpdate and _update separately (use case is that we have few operations that we need to validate, and we want to proceed with them only if all are safe to follow).

This makes above design not perfect, as either we're forced to use _update as if it was public API, or we need to run update which repeats the validation step that was already done.

I see two solutions for that

• Accept the fact that update should be used, and superfluous validation is made. It shouldn't be logically perceived as more safer, just a bit slower with no harmful side effect (if performance is not big concern)
• (preferred) Make validate method return a function that will do _update. That way we do not have to reach for _update method directly. It will affect global design of validate methods, but it seems as convincing approach.

There can also be more difficult cases where we may not be able to fully validate the changes without applying some part of them (e.g imagine validation of relation between two records that are about to change, or some bigger batch update).

For that case it might be good to introduce some kind of transaction mechanism. Which will allow us to update records (it should also affect results of computed values), but without emitting events to outer world (so they're not persistently stored, or that external mechanisms does not act to them).
If transaction would fail, all changes should be reverted so initial state is reproduced, otherwise all events should propagate for outer world.
I believe it can only work as sync operation, and transaction should not span through event loops as through race condition it may collide with other updates and produce unexpected results.

So as a side note the case where async transaction may seem desirable, will not be achievable, but instead should be addressed with gradual updates, and eventual reverts done through further updates.