Data Upgrade Script Data Upgrade

So is this still in the works anywhere? I can't find anything else about it. I'd like to replace some fields with other fields using the same name but a different type, then force a reserialization of all assets but afaik the last part can be done with the existing API in asset database.

@superpig Is it still in the design phase? I'd love to test it out.

 

Also tossing my hat in for requesting this feature. I've implemented a few variants of it myself in different projects, but without native support, there are things the public API does not let us do.

Two core issues that make this unfixable for us users without a native implementation:

• If we do data upgrading in OnAfterDeserialize or OnValidate, then any UnityEngine.Object reference is not guaranteed to be available, and will often return null. Meaning upgrading any reference is essentially not possible. Sadly, as far as I know there is no other main-thread callback we can reliably hook into short of manually loading every object in the project.
  • After further testing, this does not appear to be a problem after all. While the reference's contents are not guaranteed to have deserialized, the reference wrapper UnityEngine.Object seems to be available.
    
• If we store a serialized data version on a MonoBehaviour as a [SerializeField], and that component is on a prefab instance or prefab variant, it will inherit the prefab source's serialized data version, which makes it untrustable for its actual *own* serialized version. And likewise, as far as I know there is no callback for when an object "writes to disk" (to the asset database) so we could track this more precisely, as OnBeforeSerialize is called much more broadly and AssetModificationProcessor.OnWillSaveAssets does not allow asset data modification.

Please reconsider abandoning this experimental feature, or maybe point us in the direction of ways we could fix the above issues ourselves of how to store a serialized version field that is not inherited from the prefab.

 

I think a potentially "easy" way to do this would be to let users define their own "default overrides" with an attribute for a field, as discussed here and here. This would let us mark a serialization data version field as a default override (therefore ignored by the entire prefab apply/revert/trickle system, and marked as override on creation), allowing us to create reliable script data migration. Short of this, the workarounds are unimaginably complex as far as I'm aware.