Prohibit persistent objects' changes during certain Session events #446
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Conflicts: # Orm/Xtensive.Orm/Orm/Internals/ChangeRegistries/EntityChangeRegistry.cs # Orm/Xtensive.Orm/Orm/Internals/ChangeRegistries/EntitySetChangeRegistry.cs # Orm/Xtensive.Orm/Orm/Internals/ChangeRegistries/ReferenceFieldsChangesRegistry.cs # Orm/Xtensive.Orm/Orm/Session.cs # Orm/Xtensive.Orm/Strings.resx
- new test cases - correct name for EventInfo fields
- different error message - method of disabling changes renamed
…change registration
…nges there might be scenarios when we might need to change registries even in controversial scenarios
- no double change of flag field - explicit init of field value
SystemEvents are out of scope of registration lock
# Conflicts: # ChangeLog/7.2.0-dev.txt
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is set of
Sessionevents in which changes can be not saved to database because of evens' position in execution.The user can perform certain changes in them not knowing he will lose the changes.
The events in which changes are prohibited from now on:
Events.Persisted(it is triggered after current changes are saved to database, so new changes will be registered to next persist operation and there is a chance it will not happen, for example if persist is triggered by transaction commit);Events.TransactionCommitting(it is triggered AFTER saving changes, there is no chance for next persist operation happen within current transaction);Events.TransactionCommited(current storage transaction is committed and disposed, but the user may open new one within event for some reason and try to make changes).Talking about
Persistedevent, it may or may not cause changes loss. If it is manual saving of changes followed by transaction committing or query (in case of session's Server profile) the changes will be saved to the database, but it is basically gambling, and we can't rely on this. It is safer to not allow this to happen.TransactionCommittingis regularly misinterpreted by users because of global pattern across events - Xxx-ing is before and Xxx-ed is after some action, so some users may think that if they change something in "before" event then it will be saved to database during operation. ButTransactionCommitting/TransactionCommittedbasically enframeDbTransaction.Commit()operation, saving changes not included.So, to prevent such mistakes on developing stage and to not allow such design flaws persistent objects changes were prohibited for the described events.
Session.SystemEventshave no such restrictions, we rely on the assumption that if the user uses System events, he acts more carefully, also we use them internally and may have need to perform certain changes of persistent objects within system counterparts of the described events (but not necessary).