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.char...@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<d...@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.char...@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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
