I need to review this in detail. IIRC, this is required by some modules. That "set" can manipulate trees is more or less a side-effect of the variable implementation via json-c. Replacing json-c with something that offers more performance is on the todo list for quite a while.
Rainer 2014-11-17 10:23 GMT+01:00 singh.janmejay <[email protected]>: > Bump. > > On Thu, Nov 13, 2014 at 12:13 PM, singh.janmejay <[email protected] > > > wrote: > > > Also, tests seem to pass with the change I mentioned above (set replacing > > the contents of field regardless of it being object, leaf or null). > > > > > ============================================================================ > > Testsuite summary for rsyslog 8.5.0 > > > ============================================================================ > > # TOTAL: 125 # PASS: 120 # SKIP: 5 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # > ERROR: > > 0 > > > ============================================================================ > > > > > > On Thu, Nov 13, 2014 at 12:11 PM, singh.janmejay < > [email protected] > > > wrote: > > > >> 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 > >> > > > > > > > > -- > > 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. > _______________________________________________ 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.
