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 also didn't find an entity for MESSAGE_PROPERTY nor MESSAGE_HEADER.
However the table exists.
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?
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?
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<[email protected]>:
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<[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
