I raised JIRA QPID-8192 to make bindingKey parameter mandatory in bind/unbind operations:
https://issues.apache.org/jira/browse/QPID-8192 Kind Regards, Alex On 16 May 2018 at 09:52, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > I'd argue that we should not have bindingKey as optional, but allow the > value of the binding key to be the empty string (which is what the code > actually does if it encounters a null binding key) - presumably the > mechanism for invoking operations can distinguish between no binding key > being sent, and the binding key being supplied as the empty string? > > -- Rob > > On Tue, 15 May 2018 at 23:15, Oleksandr Rudyy <oru...@gmail.com> wrote: > >> My apologies, >> >> I completely misread and misinterpreted the method description. >> Somehow I missed *all the bindings*" in my reading :( >> >> The bindingKey is optional here because, for example, for canonical >> queue binding to fanout exchange the binding key is not needed. >> Though, it is now possible to bind the same destination to fanout >> exchange multiple times in order to be able to use different >> replacement binding keys when routing message from exchange to >> exchange. >> >> >> I think that for deletion of all bindings for the given destination a >> separate method can be added in order to avoid any confusion. >> >> Kind Regards, >> Alex >> >> >> >> >> >> >> >> >> >> On 15 May 2018 at 16:26, Rob Godfrey <rob.j.godf...@gmail.com> wrote: >> > Hi Alex, >> > >> > I think the wording is at least ambiguous when you take into account the >> > fact that bindingKey is marked as optional; and that if you read it as >> > requiring an exact match of both destination and binding then the >> > wording "Deletes >> > *all the bindings*" is weird - because there can only be 0 or 1 bindings >> > matching. >> > >> > I'm not sure what the original intention in making bindingKey optional >> here >> > was - either we should make it mandatory (and require an explicit empty >> > argument for the empty string case) or we should take bindingKey not >> being >> > set as meaning delete all bindings for this destination. >> > >> > -- Rob >> > >> > On Tue, 15 May 2018 at 17:15, Oleksandr Rudyy <oru...@gmail.com> wrote: >> > >> >> Hi Olivier, >> >> >> >> The current description of unbind operation on master and 7.0.x states >> >> : Deletes all the bindings matching the given destination and >> >> bindingKey >> >> As per description the queue binding is deleted only when both >> >> destination and binding key are equal to provided destination and >> >> bindingKey accordingly. >> >> >> >> You can get existing queue bindings from Queue managed operation >> >> 'getPublishingLinks' and call unbind for every binding returned. >> >> >> >> Are you looking for an operation to delete all bindings for a given >> >> destination? >> >> >> >> >> >> Kind Regards, >> >> Alex >> >> >> >> >> >> On 15 May 2018 at 15:43, VERMEULEN Olivier <olivier.vermeu...@murex.com >> > >> >> wrote: >> >> > Hello, >> >> > >> >> > According to the apidocs/latest/exchange documentation, it's possible >> to >> >> remove all bindings for a given destination (here a queue) using the >> >> 'unbind' operation. >> >> > But when testing it, it only works when specifying both the >> destination >> >> and the bindingKey. >> >> > Is it something that should be supported or is it the documentation >> that >> >> is not correct? >> >> > >> >> > Thanks, >> >> > Olivier >> >> > ******************************* >> >> > >> >> > This e-mail contains information for the intended recipient only. It >> may >> >> contain proprietary material or confidential information. If you are not >> >> the intended recipient you are not authorised to distribute, copy or use >> >> this e-mail or any attachment to it. Murex cannot guarantee that it is >> >> virus free and accepts no responsibility for any loss or damage arising >> >> from its use. If you have received this e-mail in error please notify >> >> immediately the sender and delete the original email received, any >> >> attachments and all copies from your system. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >> >> For additional commands, e-mail: users-h...@qpid.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
