When doing an analyze there may be references to serialized files that are not included in the analyze input.
Common cases:
- analyzing only a single assetbundle or partial group of assetbundles.
- analyzing a player build that references
unity default resources file, which is copied from the editor install and is always built without typetrees.
- Upcoming case: content directory builds analyzed without the ContentLayout.json file (so no references can be resolved)
Currently such references get assigned a id for the object table, but never written. So the only sign of these references is through gaps in the normally sequential ids. We lose the extra information about these dependent objects that is present in the reference itself (the serialized filename and LFID) - that is not recorded in the database anywhere.
Unfortunately we don't have the object type or enough detail to give a lot of details about the dangling ref beyond this basic info.
The idea of this feature is to add another table, possibly called dangling_refs that would record each unresolved reference. We would record the serialized filename in the serialized file table and reference its id in dangling_refs.
So this table would have:
- assigned object id (no row will be assigned this value in the object table)
- serialized file id
- object_id (LFID of the object)
This won't take up much space and will account for all the ids that are missing from the main object table.
There can also be a dangling_refs_view which will show which objects reference the missing references, and detail of the missing references, e.g.
- source id (objects.id field) - object that that has the dangling reference
- source serialized file string*
- source object_id (objects.object_id field)
- target serialized file string - the file that was not analyzed
- target id - id assigned to the object
- target object_id / LFID - id of the object
The dangling_refs table would be written after all the objects are analyzed, based on in memory datastructures that can be used to determine which objects were referenced but never actually resolved. In other words we cannot determine that an object is missing until we have completed processing all the objects.
When doing an analyze there may be references to serialized files that are not included in the analyze input.
Common cases:
unity default resourcesfile, which is copied from the editor install and is always built without typetrees.Currently such references get assigned a id for the object table, but never written. So the only sign of these references is through gaps in the normally sequential ids. We lose the extra information about these dependent objects that is present in the reference itself (the serialized filename and LFID) - that is not recorded in the database anywhere.
Unfortunately we don't have the object type or enough detail to give a lot of details about the dangling ref beyond this basic info.
The idea of this feature is to add another table, possibly called
dangling_refsthat would record each unresolved reference. We would record the serialized filename in the serialized file table and reference its id in dangling_refs.So this table would have:
This won't take up much space and will account for all the ids that are missing from the main object table.
There can also be a dangling_refs_view which will show which objects reference the missing references, and detail of the missing references, e.g.
The dangling_refs table would be written after all the objects are analyzed, based on in memory datastructures that can be used to determine which objects were referenced but never actually resolved. In other words we cannot determine that an object is missing until we have completed processing all the objects.