-
-
Notifications
You must be signed in to change notification settings - Fork 332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v.info: Add JSON output for history #4989
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Nishant Bansal <[email protected]>
Signed-off-by: Nishant Bansal <[email protected]>
Signed-off-by: Nishant Bansal <[email protected]>
Signed-off-by: Nishant Bansal <[email protected]>
Signed-off-by: Nishant Bansal <[email protected]>
Failing Previously in the macOS CI, |
macOS: I have restarted this test. And the OSGeo4W CI error is a bit unexpected:
|
See #4990 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good overall and the generated JSON seems good too. I have just comments about code structure.
I'm still for the mapset_path
but I would be happy to discuss alternatives if anyone feels like.
I completely agree that a function is needed. With how the code is written, two separate functions seem to be more fitting. One for actual parsing and another one for JSON. Let's say we would want to write to a different format than JSON. However, my reason for wanting two functions is mostly from code reading perspective.
vector/v.info/parse.c
Outdated
JSON_Value *info_value = json_value_init_object(); | ||
if (info_value == NULL) { | ||
G_fatal_error( | ||
_("Failed to initialize JSON object. Out of memory?")); | ||
} | ||
JSON_Object *info_object = json_object(info_value); | ||
|
||
json_object_set_string(info_object, "command", command); | ||
snprintf(mapset_path, MAX_STR_LEN, "%s/%s/%s", gisdbase, location, | ||
mapset); | ||
json_object_set_string(info_object, "mapset_path", mapset_path); | ||
json_object_set_string(info_object, "user", user); | ||
json_object_set_string(info_object, "date", date); | ||
|
||
json_array_append_value(record_array, info_value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the second function which adds one record to JSON.
vector/v.info/parse.c
Outdated
json_object_set_string(info_object, "command", command); | ||
snprintf(mapset_path, MAX_STR_LEN, "%s/%s/%s", gisdbase, location, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
command and gisdbase are here inputs while there were outputs the previous calls of the function.
vector/v.info/parse.c
Outdated
G_fatal_error( | ||
_("Failed to initialize JSON object. Out of memory?")); | ||
} | ||
JSON_Object *info_object = json_object(info_value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assumes the order in the source file and in the functions calls. Perhaps safe assumption, but confusing in the context.
vector/v.info/parse.c
Outdated
void parse_history_json(char *buf, char *command, char *gisdbase, | ||
char *location, char *mapset, char *user, char *date, | ||
char *mapset_path, JSON_Array *record_array) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function ended up here just because of its name. The parsing here is parsing command line input. I don't
In the tool itself, the function is more linked to the print anyway, so just keep it there for simplicity. Actually, in the current form, it is also very much linked to that print code.
In any case, please document split the function into two and document them with a sentence or two. It took me some time to orient myself in this code although it is actually straightforward and nicely written otherwise.
Signed-off-by: Nishant Bansal <[email protected]>
Hey @wenzeslaus, thanks for the detailed review. I've tried to improve the code structure based on your feedback and will keep it in mind for next time. Could you please take a look and check if everything is covered? Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a quick reading, I have some minor suggestions.
Signed-off-by: Nishant Bansal <[email protected]>
Signed-off-by: Nishant Bansal <[email protected]>
Co-authored-by: Nicklas Larsson <[email protected]> Signed-off-by: Nishant Bansal <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job @NishantBansal2003
I wonder, with the traditional output the history is ordered, this is not evident with current json output?! Update: e.g. add a "history_no", or "event_no" or similarly named int to json output. |
The order of elements within a JSON object created by Parson may vary (i.e., they are not necessarily in the order in which we inserted them). However, the order of elements in a JSON list/array created by Parson remains the same (i.e., exactly in the order we inserted them) unless you remove elements. See: kgabis/parson#218 |
That is what I mean. The order of history is important, but this information is lost working with a json file with an array of "records" (no predictable way to know the order there, is there). It is like a database table without a pkey. Something like:
This is, I imagine, easy to implement with a counter in the read line loop. |
Signed-off-by: Nishant Bansal <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the strings are used to signal the state, I think it is better to clear them in the caller code instead of the function. It will be more clear what is happening.
I'm not sure what you mean. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
@NishantBansal2003 Thanks!
Signed-off-by: Nishant Bansal <[email protected]>
Sorry, I'm not entirely clear on your suggestion. Could you please explain in more detail where you think the strings should be cleared? |
I think he refers to |
That would be my guess too, but that’s where it is known when to clear. |
Or possibly after call to add_record_to_json(), would work as well. |
Yes, that's what I meant. Keeping the state out of the function. Sorry for not being clear. |
So is this PR ok, or your requested changes still apply? |
Signed-off-by: Nishant Bansal <[email protected]>
Fixes: #4217
Use parson to add json output format support to the v.info module for history flag.
The JSON output looks like as follows: