On Mon, Nov 17, 2014 at 10:22 AM, Francois Billard <
[email protected]> wrote:

> 2014-11-17 18:58 GMT+01:00 Matthew Ahrens <[email protected]>:
>
>> On Mon, Nov 17, 2014 at 9:39 AM, Goulven Riou <[email protected]>
>> wrote:
>>
>>>
>>> Hi Matt,
>>> thanks for your comments on the pull request
>>> we have corrected the style error and applied your suggestions.
>>>
>>> Regarding the dataset name as a key,
>>> the json are consumed by some code and we don't know in advance what key
>>> name
>>> that we will have, so list is preferable to iter over json structure,
>>>
>>
>> Is it not possible / convenient to iterate over the key/value pairs in a
>> JSON structure
>>
>
> Actually it s possible to iterate over key in a json dictionnary, but key
> should stay a key and value a value :)
>

Yes, and at least in my mind, the dataset name is the key, and the value is
its list of properties.  I think you are saying that in the JSON world, the
key should never be a variable?  i.e. you always know what the key is
beforehand?

--matt



> , when your "zfs list -o name" display :
>
> root@t0 # zfs list -o name,used,refer
> NAME                      USED   REFER
> rpool                         1.63G   404M
> rpool/ROOT              1.23G   144K
> rpool/ROOT/debian  1.23G   1.23G
>
> the key are NAME, and value are "rpool', and so on
>
> the json output :
>
> "rpool" : {
>                  "USED" : "1.63G",
>                  "REFER" : "404M"
> }
> is not good json format (rpool is the value and you have to know the key
> to get the structure which is not convenient -> you have to fetch key name
> in advance)
>
> the good format is  (what we have implemented):
> {
>                  "NAME" : "rpool",
>                  "USED" : "1.63G",
>                  "REFER" : "404M"
> }
>
> if you want the structure of a specified pool, you must specify it in the
> command as :
> "zfs list <pool name>"
>
>
>
>
>> could you explain the use case where you need dataset as key name ?
>>>
>>
>>> an other question about the -o option , did you want to block the -o
>>> option with the -J option ?
>>>
>>
>> I thought the whole point was to use -J with -o.  Without -o, you will
>> get whatever the default properties are, which could conceivably change
>> over time.
>>
>>
> it's already the case in our implementation.
>
>
>> --matt
>>
>>
>>> best regards
>>> Goulven
>>>
>>
>
> Regards,
> Francois
>
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer

Reply via email to