Grid Deduplication Analysis Report¶
Date: 2026-02-27 (updated)
Sources: V8 Grid Baseline (03-v8-grid-baseline.md), V17 API Results, Migration Tool
Purpose: Quantify element type duplication across the 14 migrated Grid datatypes and document deduplication decisions.
Current Status: ANALYSIS COMPLETE, DECISIONS FINAL¶
| Topic | Decision | Rationale |
|---|---|---|
| Layout deduplication | DO NOT DO | Zero identical layouts confirmed (Report 11). Different allowed editors per datatype. |
| Area wrapper deduplication | DO NOT DO | Tightly coupled to layouts and editor allowlists. |
| Settings deduplication | DEFERRED | 29 potential savings, but GUID remapping risk across all client databases outweighs benefit. |
| Path A/B duplicate elimination | DONE | Migration tool fixed (3 commits). ~25 duplicates eliminated on fresh run. |
| Per-datatype architecture | CONFIRMED CORRECT | Intentional design for editor permission isolation. Documented in Report 12. |
| Test DT 2236 | DEFERRED | Not validated across all client databases. 10 element types saved if removed. |
Architecture Assessment: Per-Datatype Design is CORRECT¶
The migration tool creates element types per v8 Grid datatype. This is intentional:
- Each datatype defines different allowed editors per area (e.g., Standard Page Grid allows 44 editors in fullwidth; Contact Us Grid allows 8)
- Layout element types reference different Area Wrappers with different
specifiedAllowancelists - Content element types ARE correctly shared (not per-datatype)
Report 11 programmatically compared all shared layout names across all 13 BlockGrid datatypes and confirmed: zero layouts are truly identical. Every datatype has a different set of allowed content element types. Layout/area wrapper deduplication would either break editor permissions or require a superset of allowed editors (over-permissive).
Element Type Counts¶
Per-DataType Breakdown¶
| V8 DT ID | V8 Name | Layouts | Area Wrappers | Row Configs | Settings (3 types) | Subtotal |
|---|---|---|---|---|---|---|
| 1055 | Article Controls | 3 | 6 | 3 | 3 | 15 |
| 1093 | Contact us Grid | 2 | 3 | 3 | 3 | 11 |
| 1127 | Footer Grid | 6 | 18 | 1 | 3 | 28 |
| 1151 | Homepage Grid | 4 | 8 | 1 | 3 | 16 |
| 1257 | Standard Page Grid | 17 | 45 | 3 | 3 | 68 |
| 1459 | Full Width Grid Bottom | 2 | 3 | 2 | 3 | 10 |
| 1534 | Animated Grid | 3 | 6 | 3 | 3 | 15 |
| 1683 | articleGrid | 3 | 6 | 1 | 3 | 13 |
| 1709 | Cookie Grid | 4 | 8 | 1 | 3 | 16 |
| 1736 | Full width Grid | 3 | 6 | 1 | 3 | 13 |
| 1780 | services Grid | 2 | 2 | 1 | 3 | 8 |
| 1798 | Sp with Nav Left Grid | 3 | 6 | 1 | 3 | 13 |
| 1803 | Standard Page Full Width | 8 | 14 | 3 | 3 | 28 |
| 2236 | test data type | 2 | 3 | 2 | 3 | 10 |
| Per-DT Subtotal | 62 | 134 | 26 | 42 | 264 | |
| Shared | builtins + content types | -- | -- | -- | -- | 39 |
| GRAND TOTAL | 303 |
Standard Page Grid (1257) dominates with 68 element types due to its 17 unique row layouts.
Settings Type Analysis¶
Five distinct row settings signatures, three cell settings signatures, and five block settings signatures exist across the 14 datatypes.
Settings Deduplication Summary¶
| Settings Type | Total | Unique Signatures | Potential Savings |
|---|---|---|---|
| Row Settings | 14 | 5 | 9 |
| Cell Settings | 14 | 3 | 11 |
| Block Settings | 14 | 5 | 9 |
| Total | 42 | 13 | 29 |
Why Settings Dedup is Deferred¶
Even though 29 settings element types are structurally identical within their signature groups, each instance has unique GUIDs (generated from settings_{dataTypeId}_{settingsType}). Content data references these unique GUIDs, so merging would require:
- Updating all BlockGrid datatype configurations to reference shared settings GUIDs
- Rewriting
settingsDataarrays in every BlockGrid content value across all client databases - Consolidating database records (42 to 13) and redirecting all references
The risk of GUID remapping errors outweighs the cosmetic benefit of 29 fewer element types. Revisit only if the backoffice element type list becomes unmanageable.
Root Cause in Migration Code (Reference)¶
The per-datatype architecture stems from GridConfigurationMigrationService.MigrateGridDataTypeAsync() processing one datatype at a time with no cross-datatype awareness. GuidGenerationUtility.cs bakes dataTypeId into every GUID:
// Layout element types
public static Guid GenerateForLayoutElementType(int dataTypeId, string templateName)
=> GenerateFromString($"layout_{dataTypeId}_{templateName}");
// Content element types (correctly shared -- no dataTypeId)
public static Guid GenerateForContentElementType(string editorAlias)
=> GenerateFromString($"content_{editorAlias}");
Content element types use only editorAlias (no dataTypeId) and ARE correctly shared. Infrastructure types (layouts, area wrappers, settings) use dataTypeId for namespace isolation. This is the correct design -- documented in Report 12.
Shared Codebase Constraint¶
This codebase is shared across multiple credit union databases. All 14 datatypes must be migrated even if unused in progresscu.ie. 9 of the 14 datatypes have zero content in this database but may have content in other clients' databases.
Any future deduplication must work correctly for all client databases simultaneously.