ohai,
is there a way to specify chef search against top level attributes only?,
i.e. currently
search(:node, ‘foo:bar’) will return nodes that has node.foo as well as
node.baz.foo attribute. This is problematic, as we use many community
cookbooks, which infuses their attributes, and if by chance they specify an
attribute with same name, but under the cookbook’s name space, chef search
will still return those. Its difficult to predict the outcome of such
search queries,
afaik attributes are stored as flat docs in solr where nesting is replaces
with _. So, foo.bar.baz becomes foo_bar_baz, similarly borked.foo.baz
will become borkd_foo_baz . if this is true, is there a way to specify
the beginning of a document like ^ in regex? So that i can only get the top
level attributes, not those which are nested .
ohai,
is there a way to specify chef search against top level attributes only?,
i.e. currently
Currently, I do not think there is a way to trick the search index into
limiting results in this way.
afaik attributes are stored as flat docs in solr where nesting is replaces
with _. So, foo.bar.baz becomes foo_bar_baz, similarly borked.foo.baz
will become borkd_foo_baz . if this is true, is there a way to specify
the beginning of a document like ^ in regex? So that i can only get the top
level attributes, not those which are nested .
That's the gist of it, yes. To index a Chef object, a JSON
representation is "flattened and expanded". The flatten part is about
ending up with a list of key value pairs to index. The expand part is
what you describe above, capturing the different levels of nesting in
the JSON structure. The pro for this approach is being able to search
for deeply nested things without knowing the entire path; the con for
this approach is getting hits for deeply nested things when you don't
want them
As a workaround, you can post-filter the search results.
A hack might be to add a special character to top-level keys when we
index them (add them to the index with the sprecial prefix and
without). Then we could define a query syntax like you proposed to pick
them up (we already customize the query parsing so this wouldn't be
huge).
