Keeping in mind future extendibility we came to the conclusion that the current API schema does not support the attribute values best. It bases on attribute value type which basically comes down to string, numeric representations shared among different attribute types.
Whenever a change is required it touches all other attribute types with the same value type.
Your current query looked probably something like this
With the new schema, you can write the query with a very similar result in mind - grouping the values by the represented value type.
Since the option attributes are represented in a different way - now representing entire options rather than their codes the output in those types is a bit different those values will have to be returned differentely
The new schema also grants you the possibility of easier unpacking of specific attribute types. Since AttributeValue
type also recevided specific per attribute type you can write queries with conditional on this level - note unit and price attributes - there's no need to make separate unpacking of attribute list and values.
Wrapping things up the new value schema allows you not only to write a query providing a very similar result to the previous approach but also we trust is much more flexible and resistant to future changes.