We have a need to store some "content set" data on Products for the
certificate service to operate properly, but we're looking to avoid
the introduction of Product -> a new ContentSet object as it feels too
bound to a particular domain. Rather, we're looking to store it as
something more like an attribute on the product as we have today.
Problem is, attributes today are currently just a simple:
"key": "value"
For this use case, we'd be looking to store an attribute more like:
"content_sets": [
{"name": "content1",
"description": "description 1",
"architectures": "x86 x86_64",
"version": "5"},
...
]
I don't think it's logical to try to model this with an actual
database structure, as the attribute values could then be just
strings, hashes, or lists (of strings or hashes), it just starts to
look too crazy.
The only two options I can see are:
1) Store it as a JSON string. All rules and service adapters in this
deployment of candlepin would need to know implicitly that this
attribute maps to a json string, but this is probably fine as those
attributes are all only known to the specific rules/adapters anyhow.
2) Bite the bullet and add a ContentSet object (possibly under another
name) and relate it to the Product. Simpler mapping, but it's adding a
new concept we may not need.
Thoughts? I think I'm leaning towards 1.
Devan
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca