Hi, that's me again,
I just posted some questions on openjpa ml.
If we want to keep JPAStreamingMessage without intermediary tables, we
may use the proprietary @ElementJoinColumn annotation.
For other features, such as index creation, we also probably need
proprietary annotations.
For
Hi Tim,
Sorry, message_id was indeed needed in the patch, otherwise you've got
a id column which is pk and fk.
I still made some additional tests, and omitting the @JoinColumn also works.
DB is created and mail delivery is correctly working when you apply on
JPAProperty.
As soon as you apply
Hi Eric,
You will find attached (removed from ml, so bcc to you):
seems like attachments are not stripped via ML, both emails here have
the patch attached.
I have to define the OneToMany on the concrete class (the JPAMessage).
Yes, that's what I tried then. If this is done without changing
Hi Tim,
I'm a big fan of autoincrement pk columns per table. Each table has its
own responsiblity, and keys are generated sequentially per table.
This gives however requirements when you migrate via export/import to
fresh database. For example, with Derby, the schema is create with
GENERATED
Hey Eric,
For example, with Derby, the schema is create with
GENERATED ALWAYS columns and not GENERATED BY DEFAULT.
Why's that? Wouldn't GENERATED BY DEFAULT solve this problem so we could
happily use autoincrements?
We could also define a key-generation-table per table, but I find this
Hi Tim,
I implemented the standard @OneToMany (not the proprietary extension)
without intermediary table and the schema is created.
As you described, it hanged the first, but recompiling and relaunching
made it happen.
I'm working now on an issue when inserting mail (fk is not set). I think
a
Eric,
I implemented the standard @OneToMany (not the proprietary extension)
without intermediary table and the schema is created.
As you described, it hanged the first, but recompiling and relaunching
made it happen.
could you please send me a patch for this? I always recompiled and
Hi Tim,
comments inside..
2010/6/10 Tim-Christian Mundt d...@tim-erwin.de:
Hi,
Am Donnerstag, den 10.06.2010, 19:56 +0200 schrieb Norman Maurer:
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
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
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
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
Hi,
Am Donnerstag, den 10.06.2010, 19:56 +0200 schrieb Norman Maurer:
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
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
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
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,
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
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
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
Hi all,
I would like to cut a milestone of the current imap-trunk once the
james-project votes pass.. Anything which you would like to get fixed
before a milestone release ?
Bye,
Norman
-
To unsubscribe, e-mail:
Good luck with your exams.. Please cast your vote for james-project before
concentrate on your exams please ;)
I will take care of the milestone then..
Bye,
Norman
Am 12.01.2010 um 18:59 schrieb Robert Burrell Donkin:
(this is probably the last you'll hear from me until my exams are done)
20 matches
Mail list logo
