3 ms·

The article is not advocating flattening willy nilly. The point is to have bias for flatter structures to make it easier for the user, but of course not all str

The article is not advocating flattening willy nilly. The point is to have bias for flatter structures to make it easier for the user, but of course not all structures can or should be flat. On the other hand, don’t over-engineer your data structure so it makes finding things difficult. Grabbing an attribute is not necessarily any harder in a deeply nested structure, but filtering based on multiple deeply nested attributes in different branches can make a query quite complex.

nyuszika7h 5y ago
> The article is not advocating flattening willy nilly. It certainly seems like it does when the first example for flattening is oversimplifying an already simple structure that doesn't really need flattening. Maybe that was not meant to be a serious example but rather just for ease of understanding, but then the article should have probably said so. > filtering based on multiple deeply nested attributes in different branches can make a query quite complex Can you elaborate on this please? Maybe I'm just too tired to think clearly at 1 am, but I don't see how filtering is any harder. You would just do something like `jq '.foo | select(.bar.baz >= 42 and .qux.moo.asd == "abc")`.
- kbrazil 5y ago
  I can’t think of one off the top of my head, so maybe I’m misremembering why I originally decided I preferred flatter structures. It’s possible it was due to some limitation on my part as I was first learning to work with JSON. Looking back at some other JSON output, like `ip addr`, I’m not seeing anything egregious. There are just a couple useless top-level keys in the `iostat` output that make the queries longer and don’t seem to add value. Using the flat structure with a type field lends itself well to lazily outputting JSON lines, so maybe that’s why I tend to represent cli output that way. It’s sort of how you would format the data when sending to ELk or Splunk. Since I initially thought of JC as a cli tool, I was trying to reduce line length. Even the name JC was selected so it wouldn’t significantly increase the line length. So not nesting data inside meta objects is something I would encourage.
- Supermancho 5y ago
  > It certainly seems like it does when the first example for flattening is oversimplifying an already simple structure that doesn't really need flattening. For the purposes of making an example of how the concept is applied, making a verbose example is counterproductive. This doesn't require explanation because developers don't make work for themselves they don't need to, in practice.
- preseinger 5y ago
  That jq expression is surely more difficult to summon than a line-based grep pattern.
  - kbrazil 5y ago
    Grep would not be able to do numeric comparison, would it?
    - preseinger 5y ago
      Not directly, but once you want to do that, IMO, you've moved out of "shell script" territory and into "actual program" territory.

nyuszika7h 5y ago

> The article is not advocating flattening willy nilly. It certainly seems like it does when the first example for flattening is oversimplifying an already simple structure that doesn't really need flattening. Maybe that was not meant to be a serious example but rather just for ease of understanding, but then the article should have probably said so. > filtering based on multiple deeply nested attributes in different branches can make a query quite complex Can you elaborate on this please? Maybe I'm just too tired to think clearly at 1 am, but I don't see how filtering is any harder. You would just do something like `jq '.foo | select(.bar.baz >= 42 and .qux.moo.asd == "abc")`.

kbrazil 5y ago
I can’t think of one off the top of my head, so maybe I’m misremembering why I originally decided I preferred flatter structures. It’s possible it was due to some limitation on my part as I was first learning to work with JSON. Looking back at some other JSON output, like `ip addr`, I’m not seeing anything egregious. There are just a couple useless top-level keys in the `iostat` output that make the queries longer and don’t seem to add value. Using the flat structure with a type field lends itself well to lazily outputting JSON lines, so maybe that’s why I tend to represent cli output that way. It’s sort of how you would format the data when sending to ELk or Splunk. Since I initially thought of JC as a cli tool, I was trying to reduce line length. Even the name JC was selected so it wouldn’t significantly increase the line length. So not nesting data inside meta objects is something I would encourage.
Supermancho 5y ago
> It certainly seems like it does when the first example for flattening is oversimplifying an already simple structure that doesn't really need flattening. For the purposes of making an example of how the concept is applied, making a verbose example is counterproductive. This doesn't require explanation because developers don't make work for themselves they don't need to, in practice.
preseinger 5y ago
That jq expression is surely more difficult to summon than a line-based grep pattern.
- kbrazil 5y ago
  Grep would not be able to do numeric comparison, would it?
  - preseinger 5y ago
    Not directly, but once you want to do that, IMO, you've moved out of "shell script" territory and into "actual program" territory.