2026-09-27 - AttributeTree Structure

Data Models

Previous Structure

Old

• originally was broken into a tree service and Manager and Handler services for attributeValue types
• had extended attributeValues so can handle special data such as currency values

Mint Redesign

• after object schemas moved config into addOnDataStructures
• chose to generate separate services, which was quite complicated at the time

Probable Reasons

• maintain the Manager/Handler structure
• allow for different handler services depending on each attribute use case
• (probably not reason) allow for multiple services to point at the single attribute tree structure, eg: variants and products

New Structure

• generate resources inside same service as base objType
• still have manager/handler for values
• generate valueStandard handler objType inside base service

Hardcoded Alternative

• replace Manager/Handler with hardcoded attributeValue types
• available attributeValue types could be a setting in attributeTree addOnDataStructure
• attributeTree connected to product objType
• variant will need a new attributeTree addOnDataStructure setting that points to existing attributeTree created by different objType

Hardcoded Pros

• cleaner code flow, not need to pass requests to Handler services and consolidate in Manager
• less resources created and used in requests

Hardcoded Cons

• more rigid code
• bloated logic if many complex value types are added
• core code must be updated when adding per use case Handler types