Hi Eric
thanks for your reply. I investigated it further and made more
efficient implementation which doesn't suffer with same problem as I
described in previous email.
I made an jira issue and attached proposed patch.
https://issues.apache.org/jira/browse/MAILBOX-191#comment-13557272
The patch works for me in my test, but further code change review and
test should be made in case you decide to use it.
Peter
On 16. 1. 2013 7:41, Eric Charles wrote:
Hi,
In you example, only fetch 19, 42, 46. 48 prolly comes from the way we
build/batch the message ranges...
The fetch query is parsed in AbstractMailboxProcessor [1]
messageRange() method, called for a the ranges by FetchProcessor [2].
If you look at MessageRange [3], you will see that it is always
constructed with a from and a to, and that sometimes, if only one of
those attribute is present, we use -1 (NOT_A_UID) as 'replacement'.
So this is pure James convention, not a RFC one.
Please also bear in mind that the MessageRange building is batched to
optimize large queries, so you can have something many different
MessageRanges for a single IMAP Fetch.
For the -1 convention, we could do it better, but look e.g. at the
MaildirMessageMapper which switch in function of the MessageRange type
and also uses the -1 convention.
case ALL:
results = findMessagesInMailboxBetweenUIDs(mailbox, null,
0, -1, max);
break;
case FROM:
results = findMessagesInMailboxBetweenUIDs(mailbox, null,
from, -1, max);
break;
case ONE:
results = findMessageInMailboxWithUID(mailbox, from);
break;
case RANGE:
results = findMessagesInMailboxBetweenUIDs(mailbox, null,
from, to, max);
break;
}
Thx, Eric
[1]
https://svn.apache.org/repos/asf/james/protocols/trunk/imap/src/main/java/org/apache/james/imap/processor/AbstractMailboxProcessor.java
[2]
https://svn.apache.org/repos/asf/james/protocols/trunk/imap/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java
[3]
https://svn.apache.org/repos/asf/james/mailbox/trunk/api/src/main/java/org/apache/james/mailbox/model/MessageRange.java
On 15/01/2013 16:16, Peter Kvokacka wrote:
Hello guys
I've got problem with my custom implementation of
org.apache.james.mailbox.store.mail.MessageMapper.findInMailbox(). I'd
like to ask you if I understand API correctly here and how should I
implement it.
From Thunderbird I got request
452 UID fetch 16,17:18,20:41,43:45,47,49 (UID RFC822.SIZE
BODY.PEEK[])
which is mapped to calls on MessageMapper.findInMailbox()
findInMailbox: TYPE: RANGE UID: 16:18, Full
*findInMailbox: TYPE: FROM UID: 19:-1, Full
findInMailbox: TYPE: RANGE UID: 20:41, Full
*findInMailbox: TYPE: FROM UID: 42:-1, Full
findInMailbox: TYPE: RANGE UID: 43:45, Full
*findInMailbox: TYPE: FROM UID: 46:-1, Full
findInMailbox: TYPE: ONE UID: 47:47, Full
*findInMailbox: TYPE: ONE UID: 48:48, Full
findInMailbox: TYPE: ONE UID: 49:49, Full
what I don't fully understand is why there are those marked(*) calls
with -1 as upper bound and also 48:48 despite the fact that there were
not requested in fetch request? Does -1 here mean infinity or something
else ?
Those marked calls cause me a problem in my implementation. What can I
do about it ? Can I return an empty Iterator from
MessageMapper.findInMailbox() in such situation when upper bound is -1 ?
Is this the only situation when upper bound is -1 ? If not how should I
implement it in order to avoid unnecessary calls to database system ?
Peter
