-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Orphan language is left in YAML after deleting all versions (and having no unversioned fields) #168
Comments
This is caused by all languages being ensured to be present when saving (a requisite for sitecore packages and their wacky way to creating items). Since it's not truly an error to specify a language but have no fields or versions for it, I modified the YAML formatter to simply not emit a language if nothing of value exists underneath it. |
Hi Kam. Delayed - life got in the way - I have found a way to provoke the issue we've been chatting about. If you run this - not at all pretty - snippet of code on a clean 8.2 using RC4, you end up with corrupted YAML.
The resulting YAML for one of the child items, looks like this:
I've narrowed it down some. If I remove the
Which is odd; since Unicorn/Rainbow should not be relying on event code. It's worth noting; even with the I'm not even sure where to start when it comes to debugging this issue; and my local dev environment is also a bit... sporadic right now (new PC) - but I might give it a go once I have all my projects set up again. |
Note; it might not be the exact same issue as above, as the YAML is not emitting a blank version like your initial comment above. I will try and mess with the |
Addendum: Actually. The items do not get created correctly. The "da" versioned fields have no content in them when the edit No such luck. If I disable the config file (and therefore disable Unicorn operating on these child items), the items get created correctly - |
Ok, fairly confident we're dealing with the same issue here. I expanded my code to also remove the "da" versions - and Sitecore ended up as expected with versionless items. YML however, looks faulty. Code:
YML:
And current version: Enabling or disabling
|
I am able to reproduce the same behavior with 8.2 RTM running a harness off an MVC action (see below). I extended the samples above to run both with and without EventDisabler. You're correct that Unicorn should not be affected by event disabling. However we all know how much Sitecore likes its caches, and it's all too possible that some indirect dependency on cache invalidation, say, which does depend on events being on, is preventing data from getting where it needs to go. Of course it's also possible that my code sucks ;)
|
The apparent root cause is quite interesting; it looks like due to the use of the event disabler we run into a situation where:
Example from immediate window:
|
By my estimation to provoke this issue you'd need:
Geeze @cassidydotdk you know how to find the bugs 😀 |
There's also a secondary issue of cache clearing as also noticed. I still am able to reproduce this with the Unicorn data provider disabled. To reproduce that:
As mentioned above I get the same result whether I have the Unicorn data provider active in this case or not. This is because the EventDisabler is blocking the item cache updates - so if you're doing bulk ops in an |
See #168 Previously the code to get a source item would respect database cache settings _only for the original language_ retrieved. This would cause wacky results when an item with more than one language had some operations performed on it, such as removing a version. The secondary versions would be null in the cache and the disabler setting would be ignored due to lazy loading thus resulting in field data loss.
…ntom "v2" versions to be added to newly created items This was caused by the database cache not being used when getting the item's versions to determine the serialized version number to add. When adding a new item, this would result in incorrectly selecting version 2, because the version 1 record had been already created in the database (Sitecore's data provider goes first). Thus, getting the versions for the item without data cache said it already possessed version 1, and we'd then say great we're adding v2. This fixes the problem by simply serializing the already-updated item we got without cache - which already has the version data we need. The existing versioning code is still needed for Transparent Sync items however, where no data provider has gone ahead and updated the DB already. So that is still there for cases where the source item did not come from the database.
Released in 3.3.1 |
Reported via @cassidydotdk on Slack.
Reproduction:
It will contain:
This causes confusion on deserialization.
The text was updated successfully, but these errors were encountered: