[#55] Address review: dedup type inserts, clarify comments, doc fixes

- PackedAssetsHandler: skip redundant type inserts via a HashSet (a report
  can list thousands of objects sharing a few types).
- AddType: reword the OR IGNORE comment - first insert wins is fine since the
  name for a given id matches across TypeIdRegistry and TypeTree; the case that
  matters (id missing from the registry) still gets its name from TypeTree.
- buildreport.md: capitalization and spacing.

Author: SkowronskiAndrew

Analyzer/SQLite/Commands/SerializedFile/AddType.cs

@@ -19,9 +19,12 @@ internal class AddType : AbstractCommand
         protected override string DDLSource => null;
 
         // The BuildReport PackedAssetsHandler may have already inserted a type by numeric id (with a
-        // name from TypeIdRegistry). The TypeTree name here is authoritative and identical for known
-        // ids, so ignore the conflict rather than crashing when both a report and its build output
-        // are analyzed together.
+        // name from TypeIdRegistry), so ignore the conflict rather than crashing when both a report
+        // and its build output are analyzed together. First insert wins: the name for a given id is
+        // the same whether it comes from TypeIdRegistry or the TypeTree, so it does not matter which
+        // path runs first (a mismatch would indicate a deeper problem). The case that matters is a
+        // type missing from TypeIdRegistry (e.g. an older UnityDataTool reading a newer file); the
+        // handler skips those, so the name still arrives here from TypeTree analysis.
         protected override string ConflictClause => "OR IGNORE";
 
         protected override Dictionary<string, SqliteType> Fields => new()

Analyzer/SQLite/Handlers/PackedAssetsHandler.cs

@@ -16,6 +16,11 @@ public class PackedAssetsHandler : ISQLiteHandler
     private SqliteCommand m_InsertTypeCommand;
     private Dictionary<(string guid, string path), long> m_SourceAssetCache = new();
 
+    // Type ids we have already tried to add to the types table. A single BuildReport can list
+    // thousands of objects sharing a handful of types, so this skips the redundant INSERT calls.
+    // The handler instance lives for the whole analyze, so this dedups across all reports.
+    private HashSet<int> m_InsertedTypes = new();
+
     public void Init(SqliteConnection db)
     {
         using var command = db.CreateCommand();
@@ -106,7 +111,8 @@ public void Process(Context ctx, long objectId, RandomAccessReader reader, out s
 
             // Populate the types table so views can display the type name even when the build
             // output (and its TypeTrees) is not analyzed alongside the report.
-            if (TypeIdRegistry.TryGetTypeName(content.Type, out var typeName))
+            if (m_InsertedTypes.Add(content.Type) &&
+                TypeIdRegistry.TryGetTypeName(content.Type, out var typeName))
             {
                 m_InsertTypeCommand.Transaction = ctx.Transaction;
                 m_InsertTypeCommand.Parameters["@id"].Value = content.Type;

Documentation/buildreport.md

@@ -262,7 +262,7 @@ For consistency and clarity, database columns use slightly different names than
 
 ## Limitations
 
-**Duplicate filenames:** Multiple build reports cannot be imported into the same database if they share the same filename. This is a general UnityDataTool limitation that assumes unique SerializedFile names.  The BuildReport files in the build history (introduced in Unity 6.6) intentionally have unique file names (incorporating the build session GUID), so analyze does not hit this issue when analyzing multiple entries from the BuildHistory folder.  When analyzing multiple AssetBundle build reports, or build reports from older versions of unity, be sure to assign a unique filename to each.  See also issue #36.
+**Duplicate filenames:** Multiple build reports cannot be imported into the same database if they share the same filename. This is a general UnityDataTool limitation that assumes unique SerializedFile names. The BuildReport files in the build history (introduced in Unity 6.6) intentionally have unique file names (incorporating the build session GUID), so analyze does not hit this issue when analyzing multiple entries from the BuildHistory folder. When analyzing multiple AssetBundle build reports, or build reports from older versions of Unity, be sure to assign a unique filename to each. See also issue #36.
 
 ### Information Not Exported