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 09:09:02 GMT
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=true) 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=GenerationType.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=false 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=true 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


Mime
View raw message