Norman Maurer wrote:
So store() call is an "insertOrUpdate" function, based on the unique key
of the object (mail.getName()) for that store.
So the override is a workaround or not ?
I don't understand the question.
The correct behaviour is to write a new entry the first time and to
update the same entry at following calls to store() for a Mail with the
same name (key).
To do that you should probably store the message, keep in memory its MD5
and its userkey ("key1"). When I retrieve a message you should lookup
both MD5s and userKeys. When I store a message you should check wether
the userKey already exists and update the MD5 according to message changes.
So the message must be retrievable by md5 and by the name ? Im right?
The message must be retrievable by name (key). The problem is that the
key is not always the md5 because the *user* generates the key for new
messages. So the easiest way is to keep in memory association between
keys (names) and md5.
This is not easy: if you don't want to rehash the whole repository at
each operation you probably should create an md5->messagenumber cache
and hope the message numbers are not too volatile. Then you start trying
with the cached messagenumber, retrieve it, verify the md5 is the one
you expected, if so you can continue otherwise you have to rehash the
whole repository and clean caches.
Can you give me a tip howto create such a cache ?
Lack of time now, sorry.
Not sure if this feature worth the work right now (it won't be fast
anyway, and it won't support multiple identical messages in the same store)
IS there a need for identical messages in the store ? Cause i create the
md5 with the whole message (headers to), the messages should be not
identical anyway..
If you clone a Mail and simply change its name and call the store()
method on the same repository you just should have 2 identical mails in
the repository with only the name different. Please note that the mail
name is not contained in the mimemessage source (not an header).
I currently have not investigated on when/how this could be a problem.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
