We are using vorto to wrap an archetype data type. This vorto datatype is then added as a property on a composition. This composition is then added to several other document types.
We first starting having problems with the get vorto value function returning nulls which in turn caused archetype to throw runtime errors. At first glance it appeared to be an issue with caching, but after attempting to resolve by clearing caches, regenerating xml, and republishing the site we realized that something else had to be causing the issue.
Looking deeper into the umbraco DB we noticed that on the pages where the runtime exception was occuring, the cmsPropertyData entry for that content/property type pair had the dataNText field as null whereas the pages that did not throw the runtime exception had a JSON string in dataNtext.
We had originally mitigating these errors by clearing out the rows with nulls while then adding a value to the document property in the backoffice.
The error began to crop up again several builds later however. During the debugging process for this error we noticed that when a document that had the composition containing the data type was accessed or created and no entry for the document+propertyid existing in cmspropertydata that a new row was created for it with the dataNtest field set to null.
Looking again at the xml cache (app_data/umbraco.config) we noticed that documents with null entries were missing the property in the xml whereas the ones with values had the property.
There appeared to be issues that when the vorto property on a document was updated/added (in this case, a fieldset was added to the property) the xml cache would not add this property to the xml node corresponding to the document. The result of this behavior is that although a value was added to the document and the database has a value in dataNtext, that the document in question would still result in a runtime error if accessed. The solution at this point is to regenerate the xml, but this is not a reliable or robust solution.
I am not familiar with the conditions under which umbraco bypasses the umbraco.config file to pull directory from the DB but it does not seem to trigger in the case of this data type.
I also worry that because the default value put in dataNtext is null and not the empty languages/vorto json object that behavior like the cache not regenerating will become more commonplace as our site becomes more complex.
Is there a mechanism for controlling what the default value is for dataNtext is?
Does anyone have suggestions as to how to proceed and mitigate these runtime errors?
cmsPropertyData dataNText field NULL instead of {"values":{"lang": []}} etc.
Situation:
We are using vorto to wrap an archetype data type. This vorto datatype is then added as a property on a composition. This composition is then added to several other document types.
We first starting having problems with the get vorto value function returning nulls which in turn caused archetype to throw runtime errors. At first glance it appeared to be an issue with caching, but after attempting to resolve by clearing caches, regenerating xml, and republishing the site we realized that something else had to be causing the issue.
Looking deeper into the umbraco DB we noticed that on the pages where the runtime exception was occuring, the cmsPropertyData entry for that content/property type pair had the dataNText field as null whereas the pages that did not throw the runtime exception had a JSON string in dataNtext.
We had originally mitigating these errors by clearing out the rows with nulls while then adding a value to the document property in the backoffice.
The error began to crop up again several builds later however. During the debugging process for this error we noticed that when a document that had the composition containing the data type was accessed or created and no entry for the document+propertyid existing in cmspropertydata that a new row was created for it with the dataNtest field set to null.
Looking again at the xml cache (app_data/umbraco.config) we noticed that documents with null entries were missing the property in the xml whereas the ones with values had the property.
There appeared to be issues that when the vorto property on a document was updated/added (in this case, a fieldset was added to the property) the xml cache would not add this property to the xml node corresponding to the document. The result of this behavior is that although a value was added to the document and the database has a value in dataNtext, that the document in question would still result in a runtime error if accessed. The solution at this point is to regenerate the xml, but this is not a reliable or robust solution.
I am not familiar with the conditions under which umbraco bypasses the umbraco.config file to pull directory from the DB but it does not seem to trigger in the case of this data type.
I also worry that because the default value put in dataNtext is null and not the empty languages/vorto json object that behavior like the cache not regenerating will become more commonplace as our site becomes more complex.
Is there a mechanism for controlling what the default value is for dataNtext is?
Does anyone have suggestions as to how to proceed and mitigate these runtime errors?
is working on a reply...