Conversation
… inside a transaction
Contributor
Author
|
@yegor256 take a look please, happy to clarify anything about the change. |
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
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.
When every key of the Hash form of
Fbe.overwritewas new to the fact, the in-place branch set them one by one on the live fact. UnderFbe.fbthe rules checked the fact after each single assignment, so a pair such asrepositoryandwhere, which the rules accept only together, failed or passed depending on the order of the keys, and a failure left the first key behind in a fact that no longer matched the rules.The in-place branch now finds the fact by its identifier inside
fb.txnand adds the properties there, so the rules see the finished fact once and a failure rolls all of it back, the same way the recreate branch already works. A fact without an identifier is still filled directly. That only happens on a plainFactbase, where there are no rules to break, andFbe.repeatedlydepends on it for its first marker. If the identifier no longer points at any fact,Fbe::Erroris raised with the same message the recreate branch uses.Callers should read the fact again from the factbase after the call, as they already have to after a recreate, because the transaction commits a fresh copy of the fact.
Closes #1242