You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Items would become out of sync because we had $localizations and $origin properties on the Entry objects.
When they would get pulled from the cache, they would contain references to older Entry instances.
e.g. This flow:
Entry is created
Localization of that entry is created.
Leave a field unlocalized. The behavior should be to fall back to whatever is in the origin entry.
The $origin property has the original entry which contains its values.
Save the localization, the object instance gets placed into the cache.
Edit that field in the original entry, and save it.
Load the localization.
Since the origin was still directly on the property, it doesn't attempt to load a fresh version.
The incorrectly cached origin entry still contains an old value.
The localized entry's field appears outdated.
The $localizations causes a similar issue.
Re-save an entry that already has localizations. The array is saved on the property.
Save a localization.
Load the origin entry, it still contains references to outdated localizations.
This is fixed by removing the properties. Blink is used instead to optimize repeated queries, which is the reason for the property caches in the first place.
Now when you load entries from the cache, since the properties aren't there, the related entries need to be requeried and will be up to date.
On save/delete, we save descendant entries in order to bust the blink caches, as well as busting the ancestor's blink caches.
It worked fine in the browser because the blink would be empty on the next request.
In the test its all one process, and the blink would stick around.
This would be the same problem in a worker too.
variables test now needs make sure that localizations get added onto the global itself. the way the test was written wasn't a realistic setup. you'd need to add the localizations in reality anyway.
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
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.
Replaces #7339, thanks @wanze!
Items would become out of sync because we had
$localizationsand$originproperties on the Entry objects.When they would get pulled from the cache, they would contain references to older Entry instances.
e.g. This flow:
$originproperty has the original entry which contains its values.The $localizations causes a similar issue.
This is fixed by removing the properties. Blink is used instead to optimize repeated queries, which is the reason for the property caches in the first place.
Now when you load entries from the cache, since the properties aren't there, the related entries need to be requeried and will be up to date.
On save/delete, we save descendant entries in order to bust the blink caches, as well as busting the ancestor's blink caches.
By re-saving all the descendant entries, these issues also get resolved: