james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: [IMAP] Cut a milestone ?
Date Thu, 10 Jun 2010 17:56:46 GMT
After thinking a bit more about it, could it be that the two tables
are used for mapping ? I think that would make sense because we have a
many relation here..

So one for mapping Message and Properties and one for Message and Header.

Bye,
Norman


2010/6/10 Eric Charles <eric.charles@u-mangate.com>:
> Hi Norman,
>
> - I will also try to see what happens with the foreign keys.
> - MESSAGE_PROPERTY and MESSAGE_HEADER are created today during a fresh
> install.
> - Yes, input  from community is welcome for the primary key generation
> strategy. Anyone?
> - I now better understand JPAMessage streaming. Many tks for the
> explanation. Will also look for derby (maybe with latest 1.6).
>
> Back to MailboxMembership, I was happy to see uid is part of the
> MailboxMembership. It's good that a mail copy get a new UID.
>
> As Tim, I don't often copy mails: the "space" argument should not be
> retained.
> The memory argument is interesting for database that does not support
> streaming. I'm just wondering when the mail is completely loaded: during
> mail list when a client consults a server or only during attachment
> download?
> We should also stick to a common strategy for all stores (jcr, jpa,...). Is
> JCR also working with a temporary structure linking Mailbox and Mail?
>
> Tks,
>
> Eric
>
> On 06/10/2010 11:09 AM, Norman Maurer wrote:
>>
>> Hi Eric,
>>
>> comments inside...
>>
>> 2010/6/9 Eric Charles<eric.charles@u-mangate.com>:
>>
>>>
>>> Hi,
>>>
>>> A stable database schema would be great.
>>> Upgrading jars is straightforward, but changing the db schema (and
>>> potentially the datas) is always a pain.
>>>
>>> I had a look at the generated tables (see the list after the text).
>>> All have primary key and unique constraints, but there are no foreign
>>> keys
>>> (no constraints integrity).
>>> The buildSchema(ForeignKeys=ue) does not seem to create something for the
>>> @ManyToOne.
>>> Or maybe is this specific to derby (I'm using), and other databases such
>>> as
>>> mysql,... behave differently?
>>>
>>
>> I need to check, I'm currently using JCR so no idea atm..
>>
>>>
>>> I also didn't find an entity for MESSAGE_PROPERTY nor MESSAGE_HEADER.
>>> However the table exists.
>>>
>>
>> Maybe somthing from the "good old days" ? does they get created on a
>> fresh install ?
>>
>>
>>
>>>
>>> As far I can understand, the primary keys are all generated via the
>>> default
>>> OPENJPA_SEQUENCE_TABLE.
>>> I often let each the table auto_generate the primary keys
>>> (strategy=nerationType.IDENTITY). Are there any plans for this in the
>>> future, or will we remain with the unique default OPENJPA_SEQUENCE_TABLE?
>>>
>>
>> I have no strong opinion here.. Anyone ?
>>
>>
>>>
>>> About MailboxMembership, Tim, you said the whole message is not loaded
>>> tks
>>> to streaming.
>>> Right now, openjpa.streamingĂșlse in database.properties but when I look
>>> JPAMessage implementation, it seems that the content is loaded via
>>> InputStream.
>>> So what is the current state? Should the openjpa.streaming property be
>>> removed?
>>>
>>>
>>
>> Let me try to explain it.. When you have a look at JPAMessage you see
>> it use a byte[] object to store the message content. So once you need
>> to read the content, the whole content get loaded in memory. Thats the
>> default and work for every db. If you use openjpa.streaming=ue it
>> will stream the content direct from the db. So it never need to load
>> the content into the memory at all. This only works for a few
>> databases (derby is not one of them). Thats why it is false by
>> default.
>>
>>
>>
>>
>>>
>>> Sorry for my "in-vrac" comments. Each of them may worth a separate
>>> thread.
>>> Tks,
>>>
>>> Eric
>>>
>>> MEMBERSHIP
>>> JAMESUSER
>>> MAILBOX
>>> HEADER
>>> MESSAGE
>>> MESSAGE_HEADER
>>> MESSAGE_PROPERTY
>>> DOMAIN
>>> SUBSCRIPTION
>>> PROPERTY
>>> BAYESIANANALYSIS_SPAM
>>> VIRTUALUSERTABLE
>>> BAYESIANANALYSIS_MESSAGECOUNTS
>>> BAYESIANANALYSIS_HAM
>>> OPENJPA_SEQUENCE_TABLE
>>>
>>> On 06/09/2010 10:18 AM, Norman Maurer wrote:
>>>
>>>>
>>>> Right,
>>>>
>>>> I think we should at least be sure to not change the layout anymore. I
>>>> don't have a strong opinion on the double storage vs. single storage.
>>>> If we don't need the single storage we could just "merge" Document and
>>>> MailboxMembership interface.
>>>>
>>>> Bye,
>>>> Norman
>>>>
>>>>
>>>> 2010/6/9 Tim-Christian Mundt<dev@tim-erwin.de>:
>>>>
>>>>
>>>>>
>>>>> Hi!
>>>>>
>>>>> There is this one change of the database layout which should be decided
>>>>> upon
>>>>> before releasing, I think. Messing with code after the release is fine,
>>>>> but
>>>>> changing the database would be bad. I'm talking about Normans idea to
>>>>> unite
>>>>> the Message and Membership interfaces/classes = tables. The original
>>>>> idea
>>>>> of separating those was not to pass the whole mime message around when
>>>>> just
>>>>> the flags are needed. Moreover, the Membership part would serve as a
>>>>> reference to the Message so that a copy would just mean another
>>>>> reference
>>>>> to
>>>>> the same mail.
>>>>>
>>>>> The question: does the increased complexity really pay off? I think
>>>>> saving
>>>>> space is not really an argument because it's not really common to have
>>>>> duplicates (at least in my experience). And loading the "whole message"
>>>>> would not mean the contents but only a stream handler, not a memory
>>>>> killer,
>>>>> right?
>>>>>
>>>>> Regards
>>>>> Tim
>>>>>
>>>>> Eric Charles:
>>>>>
>>>>>
>>>>>>
>>>>>> Running here without any problem jpa (embedded derby) + jdbc
>>>>>> domainlist
>>>>>> +
>>>>>> spamassassin + forwarding mailet.
>>>>>> When do you think to release?
>>>>>> Tks,
>>>>>> Eric
>>>>>>
>>>>>> On 06/07/2010 04:51 PM, Norman Maurer wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thx mate..
>>>>>>>
>>>>>>> I deployed fresh trunk and everything seems to work so far without
>>>>>>> problems :)
>>>>>>>
>>>>>>> Bye,
>>>>>>> Norman
>>>>>>>
>>>>>>> Ps: I'm using JCR Mailbox
>>>>>>>
>>>>>>> 2010/6/7 Eric Charles<eric.charles@u-mangate.com>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I will deploy a fresh trunk this night just to make sure
everything
>>>>>>>> is
>>>>>>>> still
>>>>>>>> ok (cfr last commits in protocol,..).
>>>>>>>> The last snapshot I took is 2 weeks-old and is really stable.
>>>>>>>>
>>>>>>>> Tks,
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/07/2010 04:40 PM, Norman Maurer wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I think all the stuff in the imap library is now very
usable. I
>>>>>>>>> think
>>>>>>>>> we should cut a milestone and then cut one of james server.
>>>>>>>>> Anything
>>>>>>>>> you guys want to get refactored before ?
>>>>>>>>>
>>>>>>>>> Bye,
>>>>>>>>> Norman
>>>>>>>>>
>>>>>>>>> Ps: Even if we discover a bug later we can cut just another
one..
>>>>>>>>> Release often, Release early (urgh...)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>>
>>
>> Bye,
>> Norman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message