ottoka commented on PR #1111: URL: https://github.com/apache/james-project/pull/1111#issuecomment-1209422203
OK, turns out honoring the fetch type breaks MemoryMessageMapperTest (and MemoryMessageWithAttachmentMapperTest), in different ways: 1. The messagesRetrieved... tests want bodyStartOctet to stay the same, regardless whether there actually is a body (HEADERS), or whether there are any preceding headers in the content at all (BODY). Effectively, have the messages **lie about** what they actually have in their content byte array. I can change the code to make it so, but I worry what happens if someone actually wants to retrieve the content? 2. Some messagesRetrieved... tests basically want BODY and FULL to be the same thing in regard to findInMailbox(). A quick comparison shows that CassandraMessageMapper does exactly that, so fine. And incidentally, JPAMessageMapper also ignores the fetch type, meaning it will use a lot of memory on bulk search/retrieve operations. Oh well. 3. The deleteMessages... tests are doing something strange during AbstractMessageMapper.updateFlag(). They first retrieve messages with fetch type METADATA and the save them via InMemoryMessageMapper.save(), which **copies the truncated message** and thus winds up with a broken message in the store?? So, this mechanism actually **relies** on MessageMappers to ignore the fetch type??? At this point things are getting too weird for me, and I am not sure how all this is actually supposed to behave. Help please? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
