[
https://issues.apache.org/jira/browse/QPID-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339439#comment-15339439
]
Rob Godfrey commented on QPID-7305:
-----------------------------------
{quote}
* The private AbstractQueue#parseSelector is unfortunatly placed in between
public methods
{quote}
I'm pretty sure we've never adhered to any standards around this, and I
wouldn't really support any if we did. Personally I prefer related methods to
be group together rather than grouping by visibility.
{quote}
* formatting on CopyMessagesTransaction and MoveMessagesTransaction is off.
parameters should be on separate lines
{quote}
We've never really applied any consistency here either. The way IntelliJ has
formatted when I added parameters isn't particularly nice, but it's not
something I would lose sleep over
{quote}
* I object to limit == 0 meaning unlimited in QueueEntryTransaction. I am of
the opinion that a limit == 0 has a well defined meaning: Return 0 entries.
Whether that is useful or not, I think arbitrarily changing well defined
semantics is a mistake. Obviously if this is changed the anonymous
QueueEntryVisitor in QueueEntryTransaction needs to change as well.
{quote}
Personally I went back and forth on this. Honestly I have seen 0 been used to
mean "no limit" at least as often as it is used to mean "don't bring back any
rows", so I don't agree that it is arbitrarily changing semantics.
{quote}
* no tests
{quote}
Indeed - I was surprised that there don't seem to be any tests on this area of
functionality. I debated trying to add some unit tests, but it was pretty
unpleasant. I guess one could write a unit test around QueueEntryTransaction,
though I'm not sure how much value that adds. I'd agree that adding system
tests around the operations would be good.
{quote}
* no documentation
{quote}
On the contrary I did add inline documentation to the parameters of the
operations. I'd strongly argue that for this sort of change to the REST API
this is the *only* sort of documentation we should be using.
> [Java Broker] Queue operations copy/move/delete should take an optional JMS
> selector argument
> ---------------------------------------------------------------------------------------------
>
> Key: QPID-7305
> URL: https://issues.apache.org/jira/browse/QPID-7305
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Keith Wall
> Fix For: qpid-java-6.1, qpid-java-6.0.4
>
>
> The Queue defines three operations which act on a provided subset of the
> messages on the queue: copy/move/delete.
> The caller of the operation must provide a list of (internal) message-ids on
> which they wish the operation to be performed.
> It would be useful to be able to supply a JMS selector in addition / in place
> of the list of message ids. This would allow a user to construct a selective
> query as to which messages get moved/copied/deleted (or simply
> move/copy/delete all messages in the queue).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
