Am Sonntag, den 26.03.2006, 17:21 +0200 schrieb Stefano Bagnara: > Norman Maurer wrote: > > Just one quick question for add this features.. > > > > you said: > > that multiple calls to store(Mail) using the same mail will create a new > > object in the store the first time and update the same object the > > following calls. > > > > So if store(Mail) is called again with the same email (what you mean > > with same ? identical?) it should override the "old" email ? Or what for > > updates you talk about? > > Storing a message with the same name (key) in a store where the same > name already exists overwrites it. > > 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 ?
>
> We should change the whole repository interface because this is a big
> limitation of the current interfaces but we can't do this for 2.3.0. So
> we should either find workarounds or wait to have a 2.3.0 final and
> start working on the 3.0.
>
> BTW, I'm happy you're working on this because we can better understand
> the current interfaces and what we need to change for 3.0 in order to
> have better support of javamail stores as "message" stores.
>
> > The problem with random keys is fixed here now by generate a md5 for
> > each message and use this as Key. So the key is on every call the same
> > for each message.
>
> I try to describe a problematic scenario with metacode:
>
> // when we create mails WE assign our own names
> // the repository has no power on it.
> Mail a = new Mail(name => "key1");
> // this store the message in the repository
> repos.store(a);
> // this MUST find that message
> Mail b = repos.retrieve("key1");
> b.getMessage().setSubject("new subject");
> // this updates the same message in the store.
> repos.store(b);
>
> 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?
> 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 ?
> 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..
> As a sidenote, I already wrote about repository refactoring I think we
> should evaluate:
>
> 1) SpoolRepository and MailRepository should be merged in a single
> interface (it's easy enough to provide spoolrepository services over a
> mailrepository, so we don't need both of them). I would call the unified
> object MailRepository. We should look at the JMS interfaces for queue to
> improve our interface (e.g: the unique key should be generated by the
> repository and not by us)
>
> 2) MessageRepository: this does not persist Mail objects but only
> Messages (MimeMessages). It probably is really similar to javamail
> stores and we should provide a JavamailStoreMessageRepository.
> MessageRepositories should support a rich interface to simplify IMAP
> usages (search, folders, etc..).
>
> 3) MailRepositories could use MessageRepositories for their message
> persistence needs.
>
> 4) MessageRepositories should be able to move messages directly between
> multiple repositories (would help us to improve performance a lot when
> using uniform repositories)
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> !EXCUBATOR:1,4426b236200621930777360!
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
