After using USync to run in a new document type set to "Enable List View" into a target database, it is not possible to access newly created content for those document types. The backoffice throws a not found error, grabbed from Fiddler as:
"Message":"An error has occurred.","ExceptionMessage":"Object reference not set to an instance of an object.","ExceptionType":"System.NullReferenceException","StackTrace":" at Umbraco.Web.Models.Mapping.TabsAndPropertiesResolver.AddListView[TPersisted](TabbedContentItem`2 display, String entityType, IDataTypeService dataTypeService)\r\n at Umbraco.Web.Models.Mapping.ContentModelMapper.AfterMap(IContent content, ContentItemDisplay display, IDataTypeService dataTypeService)\r\n at AutoMapper.TypeMap.b__1(Object src, Object dest)\r\n at AutoMapper.Mappers.TypeMapObjectMapperRegistry.PropertyMapMappingStrategy.Map(ResolutionContext context, IMappingEngineRunner mapper)\r\n at AutoMapper.Mappers.TypeMapMapper.Map(ResolutionContext context, IMappingEngineRunner mapper)\r\n at AutoMapper.MappingEngine.AutoMapper.IMappingEngineRunner.Map(ResolutionContext context)"
Switching off "Enable List View" allows access to the content, but switching back on again and you get the same error.
The one difference I can see to the originating database (where everything works fine), is that in the Structure section of the doc type, where you set as List View, the originating database shows "List View - Content (Default) " and a button to "Create Custom List View" whereas the target database shows "List View - Content" (without the default) and button to "Remove Custom List View". Clicking this button actually deletes the main content list view (I ran it back in with Usync), so it seems to be linked to the right data type- but something seems to be missing...
Are there any known issues with USync and document types enabled as List View? I've searched and not found anything.
I've found out a couple of things that may be relevant-
Firstly, as the ListView data types were new as of v7, the USync files for the ListViews were only generated added to source control recently for us.
I don't understand how Umbraco determines what data type is in use- there is no cmsPropertyType record for example.
The one difference I can see between the data types is the pk field- in the source/master database that was directly upgraded, the pks of the ListView data types are negative - -26,-27 and-28. This data is not included in the USync file, and in the destination databases they have positive PKs that have been generated as USync has run them in.
I'm wondering if these negative PKs might be important, and might be how Umbraco determines that the default ListView is in use and not a custom list view...
Our strategy for dealing with Umbraco upgrades is to upgrade the main database and then use USync to push changes out to all other databases. I'm now questioning whether that strategy is correct- if Umbraco is running things like this during an upgrade then I'm going to need to run a full upgrade on all databases and can't rely on USync to manage those changes?
Having reviewed the Umbraco migrations, there aren't many, so we have left in place our current strategy and created a custom script based on this "EnsureListViewDataType" migration to cover the creation of the List View DataType/ PreValues/ umbracoNode entries.
The conclusion for us here is that USync can never cover you completely for adding new data types into existing Umbraco databases- because Umbraco does stuff like switching off Identity in order to insert records with specific primary keys which they then reference in code, USync is never going to be able to replicate this. So the data types do need to be created either through the Umbraco migration or manually with the correct primary keys.
This is something we're just going to have to keep an eye on with any future Umbraco upgrades that involve the addition of new data types.
Happy for this issue to be closed, if anything it is an Umbraco core issue, not USync
Are you saying that uSync was pushing changes out to downlevel versions of umbraco (i.e 7.2 -> 7.1?),
I suppose uSync could have a don't create attribute if it finds datatypes with negative Id? It would stop any clash (and potentially any YSOD should the new types need dlls, or anything ?
USync issue with Doc Types enabled as List View
After using USync to run in a new document type set to "Enable List View" into a target database, it is not possible to access newly created content for those document types. The backoffice throws a not found error, grabbed from Fiddler as:
Switching off "Enable List View" allows access to the content, but switching back on again and you get the same error.
The one difference I can see to the originating database (where everything works fine), is that in the Structure section of the doc type, where you set as List View, the originating database shows "List View - Content (Default) " and a button to "Create Custom List View" whereas the target database shows "List View - Content" (without the default) and button to "Remove Custom List View". Clicking this button actually deletes the main content list view (I ran it back in with Usync), so it seems to be linked to the right data type- but something seems to be missing...
Are there any known issues with USync and document types enabled as List View? I've searched and not found anything.
Versions- Umbraco 7.2.1 / USync 2.2.6 (rolled back from USync 2.4.4 due to Issue 60391-Document-type-properties-for-custom-data-types
I've found out a couple of things that may be relevant-
Firstly, as the ListView data types were new as of v7, the USync files for the ListViews were only generated added to source control recently for us.
I don't understand how Umbraco determines what data type is in use- there is no cmsPropertyType record for example.
The one difference I can see between the data types is the pk field- in the source/master database that was directly upgraded, the pks of the ListView data types are negative - -26,-27 and-28. This data is not included in the USync file, and in the destination databases they have positive PKs that have been generated as USync has run them in.
I'm wondering if these negative PKs might be important, and might be how Umbraco determines that the default ListView is in use and not a custom list view...
OK I found https://github.com/umbraco/Umbraco-CMS/blob/5b9a98ad6ae9e63322c26f7b162204e34f7fcb54/src/Umbraco.Web/Strategies/Migrations/EnsureListViewDataTypeIsCreated.cs
This is a migration script in Umbraco core code which includes:
Our strategy for dealing with Umbraco upgrades is to upgrade the main database and then use USync to push changes out to all other databases. I'm now questioning whether that strategy is correct- if Umbraco is running things like this during an upgrade then I'm going to need to run a full upgrade on all databases and can't rely on USync to manage those changes?
Having reviewed the Umbraco migrations, there aren't many, so we have left in place our current strategy and created a custom script based on this "EnsureListViewDataType" migration to cover the creation of the List View DataType/ PreValues/ umbracoNode entries.
The conclusion for us here is that USync can never cover you completely for adding new data types into existing Umbraco databases- because Umbraco does stuff like switching off Identity in order to insert records with specific primary keys which they then reference in code, USync is never going to be able to replicate this. So the data types do need to be created either through the Umbraco migration or manually with the correct primary keys.
This is something we're just going to have to keep an eye on with any future Umbraco upgrades that involve the addition of new data types.
Happy for this issue to be closed, if anything it is an Umbraco core issue, not USync
I think i understand
Are you saying that uSync was pushing changes out to downlevel versions of umbraco (i.e 7.2 -> 7.1?),
I suppose uSync could have a don't create attribute if it finds datatypes with negative Id? It would stop any clash (and potentially any YSOD should the new types need dlls, or anything ?
is working on a reply...