Follow up to #47
BuildReport files record types using the type ID, not the string name. That is good for saving diskspace and computations but its not human friendly when viewing the report data in the analyze database.
The Analyze schema has a "types" table that can be used to map from id to string, this is useful to JOIN against for views and other queries so that the human friendly type is shown.
In #47 we introduce a hard coded list of those types (for use when we don't have the string), and more recently in 0c36a90 this list was made comprehensive (so that we could use it reliably for the type argument to the dump command).
This task is to use UnityFileSystem/TypeIdRegistry.cs in Analyzer/SQLite/Handlers/PackedAssetsHandler.cs and dynamically populate the type table if the type is not already present.
Once this is done we can update build_report_packed_asset_contents_view to show the string-based type, instead of the numeric value, making it a lot easier to understand.
Follow up to #47
BuildReport files record types using the type ID, not the string name. That is good for saving diskspace and computations but its not human friendly when viewing the report data in the analyze database.
The Analyze schema has a "types" table that can be used to map from id to string, this is useful to JOIN against for views and other queries so that the human friendly type is shown.
In #47 we introduce a hard coded list of those types (for use when we don't have the string), and more recently in 0c36a90 this list was made comprehensive (so that we could use it reliably for the type argument to the dump command).
This task is to use UnityFileSystem/TypeIdRegistry.cs in Analyzer/SQLite/Handlers/PackedAssetsHandler.cs and dynamically populate the type table if the type is not already present.
Once this is done we can update
build_report_packed_asset_contents_viewto show the string-based type, instead of the numeric value, making it a lot easier to understand.