| 2013-06-26 15:00:03 |
Aaron Bentley |
description |
Elasticsearch is not a free-form data store; it uses a mapping, and that mapping has an entry for every unique key it encounters. This prevents pre-defining value types, which in turn leads to issues like bug #1176452. It also means that the mapping is so long that it is not human-readable. (The mapping for 10 charms turns out to be 1598 lines, pretty-printed.)
Instead, the representation given to elasticsearch should make all user-defined values *values*, not keys. For example:
{'foo': 'bar', 'baz': 'qux'} => [{'name': 'foo', 'value': 'bar'}, {'name': 'foo', 'value': 'qux'}]
Currently affected fields: "config.options" (but work in progress), "files", "provides", "requires", "peers", |
Elasticsearch is not a free-form data store; it uses a mapping, and that mapping has an entry for every unique key it encounters. This prevents pre-defining value types, which in turn leads to issues like bug #1176452. It also means that the mapping is so long that it is not human-readable. (The mapping for 10 charms turns out to be 1598 lines, pretty-printed.)
Instead, the representation given to elasticsearch should make all user-defined values *values*, not keys. For example:
{'foo': 'bar', 'baz': 'qux'} => [{'name': 'foo', 'value': 'bar'}, {'name': 'foo', 'value': 'qux'}]
Currently affected fields: "config.options" (but work in progress), "files", "provides", "requires", "peers".
When fixing files, it may make sense to address bug #1189992 at the same time. |
|
