plainblack.com
Username Password
search
Bookmark and Share
View All Tickets
Upgrade to 7.10 causes metadata values to "disappear"  (#12339)
Issue

Problem:

During the upgrade from 7.9.34 to 7.10.22, a new revisionDate field is added to the metaData_values table; however, this field is not updated for existing records in the table, causing each asset's metadata values to have a revisionDate of effectively 0. The metadata values are not lost from the database, but they appear to disappear from the web interface because they no longer are properly associated with the assets they were originally associated with. Before, metadata were presumably matched to assets using the assetId in the metaData_values table alone. But after adding versioning, now both the assetId and the revisionDate have to match for metadata to be appropriately associated with an asset.

This problem occurs in both the editing interface and the general web view of an asset. When you go to edit, the original metadata form elements show blank/default. In web view, anything that made use of the metadata values in templates now behave as if the metadata values were not set.

Solution:

The upgrade script should be updated to populate the revisionDate field with a value that matches up each asset with its metadata values, so that proper association between asset and metadata value is retained after the upgrade.

However, in order to preserve proper behavior among all the assets' versions and to be able to continue to roll back version tags prior to the upgrade, it seems you will need to not only update the metaData_values table, but ALSO replicate each row, once for every revision of the asset the metadata is associated with (adding the proper revisionDate for each). That way, if you view a previous version of the asset, you'll still be able to associate the metadata values (as of just prior to the upgrade) with that version. You'll also be able to roll back a version tag and not wipe out all the metadata values for a particular asset.

This will probably add significant time to the upgrade process, as well as the length of the metaData_values table, for sites that make frequent use of metadata. You might be able to economize by limiting the replication to only metadata values for which the value is something other than 0/null.

Solution Summary
Comments
Trex
0
3/8/2012 5:39 pm
I've created a utility script that can be used to update existing metadata to include proper revisionDate information on sites that have already gone through the upgrade process to 7.10. I've attached it here in case it's helpful towards getting a fix applied to the upgrade script. I'll probably add it to the market too.

The script is fully documented, so doesn't need much extra explanation here. It has a few extra flags/switches to help those who've already upgraded perform the best fix for their situation: re-set all metadata back to pre-upgrade values or only set metadata values for revisions and assets that have not yet been edited.
vanjwilson
5
3/29/2012 2:55 pm
@Trek,

Thanks so much for the metadataFixer script. The documentation was great, too.

It took about 30 seconds to fix over 8,000 assets with over 19,000 pieces of custom metadata among them.
perlDreamer
0
8/30/2012 1:48 pm
Borrowed code from Dale's script to insert metaData values with revisionDates and then wipe out the original, revisionDate-less values.

Fixed in 7.10.27 (4f74c4c)
Details
Ticket Status Resolved  
Rating5.0 
Submitted ByTrex 
Date Submitted2012-03-06 
Assigned To unassigned  
Date Assigned2018-09-22 
Assigned By 
Severity Critical (mostly not working)  
What's the bug in? WebGUI Stable  
WebGUI / WRE Version 7.10  
URLuse/bugs/tracker/12339
Keywords
Related Files
Ticket History
9/3/2012
4:49 PM
Resolved perlDreamer
3/6/2012
11:30 PM
Ticket created Trex
© 2018 Plain Black Corporation | All Rights Reserved