yv01p/Umbraco-CMS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Changes the migration script to set any unknown editors to label

Browse Source
This commit is contained in:
Shannon
2013-09-11 13:22:00 +10:00
parent d39cea7edd
commit 86d73712fd
1 changed files with 6 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
src/Umbraco.Core/Persistence/Migrations/Upgrades/TargetVersionSeven/ChangeControlIdColumn.cs
View File

@@ -31,18 +31,13 @@ namespace Umbraco.Core.Persistence.Migrations.Upgrades.TargetVersionSeven
}
else
{
//We cannot find a map for this property editor so we're going to make it a label. This is because:
// * we want the upgrade to continue
// * we don't want any data loss
// * developers can change the property editor for the data type at a later time when there's a compatible one
// * editors cannot edit the value with an invalid editor
/* what do do ?
* throw an exception? -> I can actually ensure that all GUIDs in the table currently have a valid entry in the map before running the upgrade and if not then the upgrade will just fail?
* ignore it, just leave the legacy GUID entry in there -> this will mean that the editor will not render for that property and there will probably be YSODs generated elsewhere.
* delete the entry -> of course this could lead to data loss
* change it to a text field -> no data loss and they are able to then change it to a different property editor later in the data type editor
*/
//NOTE: I'm going to just set this to a text field, I think this is the 'safest' way without data loss and still allows an upgrade, still
// waiting on feedback from the core team.
Update.Table("cmsDataType").Set(new { propertyEditorAlias = Constants.PropertyEditors.TextboxAlias }).Where(new { item.pk });
Update.Table("cmsDataType").Set(new { propertyEditorAlias = Constants.PropertyEditors.NoEditAlias }).Where(new { item.pk });
}
}
}