On Nov 18, 2014, at 10:18 AM, Matthew Ahrens <mahr...@delphix.com> wrote:
>
> On Tue, Nov 18, 2014 at 8:00 AM, Francois Billard
> <francois.bill...@alyseo.com> wrote:
> Matt,
>
> In C you use a structure with predefined fields names, it would be difficult
> to use it if names change every time ?
>
> Actually it would be easier to implement in C the way I described, because
> then you won't have to realloc the array, you can just use do
> nvlist_add_nvlist(dataset_name, nvlist_of_props).
>
> But more importantly, I presume the JSON output will become a stable
> interface. Does anyone else have opinions on this?
yes. I'd like to start with an agreed-upon stable JSON schema. Likely this will
be very similar to
the current nvlists. Having done this several times now, it really helps to get
it right up front.
[now to find some extra time...]
-- richard
>
> --matt
>
> In Python, it's technically possible to have variable as keys (interpreted
> language), you can iterate over keys list of dictionnary to know name of keys
> and after get the value (dict of properties), but it's not practical , you
> must fetch name before getting properties every time.
>
> Names must be preset to establish a rigid and well known structure of the
> output of commands and also to ensure the uniqueness of keys in dictionaries.
>
> We try also to respect the semantic of the commands output, in this case, the
> command "zfs list" return a list of zfs mount point, each mount point is a
> dictionary of properties (name, used, avail, ..). So the output should be
> identic : a list of dict
>
>
> --francois
>
> 2014-11-17 19:34 GMT+01:00 Matthew Ahrens <mahr...@delphix.com>:
>
>
> On Mon, Nov 17, 2014 at 10:22 AM, Francois Billard
> <francois.bill...@alyseo.com> wrote:
> 2014-11-17 18:58 GMT+01:00 Matthew Ahrens <mahr...@delphix.com>:
> On Mon, Nov 17, 2014 at 9:39 AM, Goulven Riou <goulven.r...@alyseo.com> 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
> developer@open-zfs.org
> http://lists.open-zfs.org/mailman/listinfo/developer
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
