Removing all the cases and replacing everything with just: json_object_object_add(parent, (char*)leaf, json);
Changes the semantics to always replace the value, regardless of it being object, leaf or null. >From the pov of set x = y, it seems like the right thing to do. But im sure the existing implementation is the way it is for a reason. In case its just a bug, should we go ahead with this replacement? (all cases removed and just one simple object_add call, no dereference of old value required either). In case its not a bug, what about having another statement (reset?) for this purpose? So, if user wants objects to be merged and object not be be replaced with leaf etc, they can use 'set $.foo = $.bar;' but if they want no-conditions replace-whatever semantics, they can use 'reset $.foo = $.bar;'. Ideally, may be we should call set something else, merge? but that may be bad from backward compatibility pov. On Thu, Nov 13, 2014 at 11:07 AM, singh.janmejay <[email protected]> wrote: > Hi Rainer, > > Im talking about msgAddJSON. Quickly glanced through your > commit(71a5122fa), but it doesn't seem to talk much about it. Why do we > disallow replacing an object with a non-object value? > > Also, not really the same issue, but another clarification in the same > area of code. Why do we merge objects when user has called 'set'? shouldn't > we replace old json_object with new one? > > -- > Regards, > Janmejay > http://codehunk.wordpress.com > -- Regards, Janmejay http://codehunk.wordpress.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
