Okay, sounds like everyone wants standardization and we’re all okay with using period (“.”) as the separator. To get where we want to go, we need to get to consensus on some things:
- How do we handle attributes that contain the separator character? I propose that Arrays should be acceptable in Ruby DSLs, e.g.:
[ “an_attribute”, “that.contains.dots” ]
Any good ideas on how we can make this usable on the command line? Give up and require people to “alias” their attributes in cookbooks if they hit this case?
- What’s the scope, and/or what parts of the problem do we want to fix at what times? As Noah mentions, this affects search (specifying the key in your query), partial search, attribute whitelisting, and ohai filtering (command line and internal). We (Chef Software) can modify the whitelist feature to use the period character since it hasn’t shipped in an official release yet. The others require either breaking changes or some kind of interface versioning. Changing search (e.g.,
knife search node ‘a.nested.key.in.search.query:value’) could potentially require a data migration. How do we see this happening, and when?
To be clear, we’re planning to go ahead and switch whitelisting to use period and array separators since the next chef release is imminent and we don’t want to add additional back compat hassles. For everything else, we should go through the chef-rfc process (https://github.com/opscode/chef-rfc/pull/17/files). Noah, do you want to write that up?
- The format of documents stored in Solr is given https://github.com/opscode/chef-expander/blob/master/lib/chef/expander/solrizer.rb#L175-188 and
On Monday, July 7, 2014 at 11:18 PM, Peter Fern wrote:
On 08/07/14 07:09, Noah Kantrowitz wrote:
Something that could maybe do with a bit of standardization. The issue is given some nested hashes, how do you indicate a specific key. The attribute declaration and the new attribute whitelists use a “/” separator, most knife command line options use a “.” and partial searches use none and require a real array. Thoughts?
I really wish this was standardized. The fact that there are at least
three ways of doing this is a real problem, and so are characters like
’.’ and ‘_’, that are frequently included in key names. My vote would
be for ‘/’ separated, or ‘[array][ish][notation]’ because that largely
does away with the conflicting separator problem, but if we could at
least be consistent within knife, that would be way less insane than
what we’re doing now.
When I wrote knife-attribute I used the dot notation because it’s
common across all the core knife commands except search, and because
that’s what’s supported by GenericPresenter#extract_nested_value, but
#extract_nested_value doesn’t even support escaping, so if you encounter
something with periods in the key, you’re completely boned. It may be
worth my while to submit a PR to at least allow escaping there, now that
it comes to mind again.
 OT: It might be a good idea to have a ‘knife’ section on the
supermarket to act as a central repository for discovering knife plugins
gem search knife-).