The current JSON representation for a model with aux data is hard to use/create since it creates additional layers of nesting at each level. A simpler JSON representation should be created before we start using JSON for schema and DB mappings.
After considering various representations, the following representation was settled upon:
The aux value for a field named abc_xyz will be in a field named abc_xyz__<aux-name>_.
Two underscores separate the field name from the aux name.
Double underscores and trailing underscores are reserved for system use. Schema validation will prevent developers from creating fields with double underscores or trailing underscores.
Using aux as a suffix helps keep aux values next to their corresponding fields.
The trailing underscore makes it easy for the system to determine if the field is an aux field or a regular field.
Elements in a list don't have field names (before each element) and will therefore need a different way of representing aux data.
The aux value for object list-elements will be inside the objects in a field named <aux-name>_
Scalar list-elements will be objects so that each scalar list-element can have its own aux data.
The value will be in a field named value.
The aux data will be in fields named <aux-name>_.
Non-list scalar fields do NOT have this additional nesting. Consistency was considered but abandoned since non-list scalar fields are common while scalar list fields are uncommon. No point making the common case worse just for consistency sake.
The current JSON representation for a model with aux data is hard to use/create since it creates additional layers of nesting at each level. A simpler JSON representation should be created before we start using JSON for schema and DB mappings.
After considering various representations, the following representation was settled upon:
abc_xyzwill be in a field namedabc_xyz__<aux-name>_.<aux-name>_value.<aux-name>_.