From: Tim Hinrichs <[email protected]> Date: Monday, January 8, 2018 at 7:31 AM To: Eric Kao <[email protected]> Cc: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Subject: Re: [congress] generic push driver
> It's probably worth considering PATCH instead of PUT for updating the table. Ah right of course. PATCH makes more sense here. > > http://restcookbook.com/HTTP%20Methods/patch/ > > You could also think about using JSON-patch to describe the requested update. > It provides fine-grained update semantics: > > https://tools.ietf.org/html/rfc6902 Hmm it would be very nice to follow an existing standard. Unfortunately the json patch path specifications seem like an awkward fit with the set semantics of congress tables. Removal, for example, must be done by specifying the array index of the row to be removed. But perhaps we can borrow the style of json patch for patching sets. For example: PATCH '/v1/data-sources/vitrage/tables/alarms' with body: [ { "op":"add", "path":"/", "value":{ "id":"1-1", "name":"name1", "state":"active", "severity":1 } }, { "op":"add", "path":"/", "value":[ "1-2", "name2", "active", 2 ] }, { "op":"remove", "path":"/", "value":[ "1-2", "name2", "active", 2 ] } ] Would that work well? At least there will be well-defined semantic based on sequential operation. > > Tim > > On Fri, Jan 5, 2018 at 5:50 PM Eric K <[email protected]> wrote: >> We've been discussing generic push drivers for Congress for quite a while. >> Finally sketching out something concrete and looking for some preliminary >> feedback. Below are sample interactions with a proposed generic push driver. >> A generic push driver could be used to receive push updates from vitrage, >> monasca, and many other sources. >> >> 1. creating a datasource: >> >> congress datasource create generic_push_driver vitrage --config schema=' >> { >> "tables":[ >> { >> "name":"alarms", >> "columns":[ >> "id", >> "name", >> "state", >> "severity", >> ] >> } >> ] >> } >> ' >> >> 2. Update an entire table: >> >> PUT '/v1/data-sources/vitrage/tables/alarms' with body: >> { >> "rows":[ >> { >> "id":"1-1", >> "name":"name1", >> "state":"active", >> "severity":1 >> }, >> [ >> "1-2", >> "name2", >> "active", >> 2 >> ] >> ] >> } >> Note that a row can be either a {} or [] >> >> >> 3. perform differential update: >> >> PUT '/v1/data-sources/vitrage/tables/alarms' with body: >> { >> "addrows":[ >> { >> "id":"1-1", >> "name":"name1", >> "state":"active", >> "severity":1 >> }, >> [ >> "1-2", >> "name2", >> "active", >> 2 >> ] >> ] >> } >> >> OR >> >> { >> "deleterows":[ >> { >> "id":"1-1", >> "name":"name1", >> "state":"active", >> "severity":1 >> }, >> [ >> "1-2", >> "name2", >> "active", >> 2 >> ] >> ] >> } >> >> Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used together >> with some well defined semantics. Alternatively we may mandate that each >> request can have only one of the three pieces. >> >> Note 2: we leave it as the responsibility of the sender to send and confirm >> the requests for differential updates in correct order. We could add >> sequencing in future work.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
