Hi Eric,
sorry, I forgot IMAP-172. Besides that I don't know of any impacts.
Tim
Am Sonntag, den 11.07.2010, 19:45 +0200 schrieb Eric Charles:
Hi Tim,
I still need time to find my way in the hard-work you did with Norman
these last 2 weeks :)
Upon IMAP-168, are there other JIRA that
You need to rename the mailbox names too:
https://issues.apache.org/jira/browse/IMAP-176
We changed #mail to #private.
Bye,
Norman
2010/7/12 Tim-Christian Mundt d...@tim-erwin.de:
Hi Eric,
sorry, I forgot IMAP-172. Besides that I don't know of any impacts.
Tim
Am Sonntag, den
Hi Tim,
So there is consensus to leave the package naming as-is and move
entities with openjpa proprietary extension to the openjpa packages.
Currently, I have no well defined patch (only many trials I made).
I will implement some @ElementJoinColumn and @Index and test it with
real traffic.
Hi Eric,
that sounds good. Let's see, if we can provide a sql-only migration
script. After solving issue IMAP-168 the database schema will change
again, so we'll have to take care of that, too.
Best
Tim
Am Sonntag, den 11.07.2010, 14:18 +0200 schrieb Eric Charles:
Hi Tim,
So there is
Hi Tim,
I still need time to find my way in the hard-work you did with Norman
these last 2 weeks :)
Upon IMAP-168, are there other JIRA that could impact the database
schema/data (IMAP-172,...?) ?
Tks,
Eric
On 07/11/2010 03:12 PM, Tim-Christian Mundt wrote:
Hi Eric,
that sounds good.
Hi Norman and Eric,
I fully agree with simply using OpenJPA annotations.
Concerning the openjpa package I think I found what you mean, Eric. It
was confusing because there are two OpenJPA packages:
org/apache/james/imap/jpa/mail/model/openjpa
org/apache/james/imap/jpa/openjpa
The latter is
At least we would not be able to add a implementation for Hibernate..
Its LGPL which is not compatible with ASL2.
Bye,
Norman
2010/6/24 Tim-Christian Mundt d...@tim-erwin.de:
Hi,
4. The majority of the classes will use openjpa classes: instead of
moving them all to
Hi Eric,
Am Freitag, den 25.06.2010, 05:16 +0200 schrieb Eric Charles:
Hi Tim,
If we set streaming by default, we can not use derby anymore as default.
well, shipping derby is obviously nice for a quick James test, we should
leave that as it is. Maybe we can find a better way to configure
Hi Tim,
Config is the price to pay for the many available options. It has also
to see with Spring, and not only with JPA. We may begin another thread
later on to talk about this.
I'm also happy with OpenJPA and using its proprietary annotations (not
classes) doesn't prohibit a
Hey,
I'm also happy with OpenJPA and using its proprietary annotations (not
classes) doesn't prohibit a developer/deployer to define another JPA
provider.
Right.
What about :
- @ElementJoinColumn ?
- @Index ?
I'd support those.
- rename 'openjpa' package to 'streaming' ?
We already
Ok so to come to some consequence here.. Let us just use the openjpa
annotation stuff.. If we really want to support other JPA
implementations we could handle it later..
Bye,
Norman
2010/6/25 Tim-Christian Mundt d...@tim-erwin.de:
Hey,
I'm also happy with OpenJPA and using its proprietary
Hi Tim,
I think (not sure) the **/openjpa packages have been defined to place
all classes that use specific/proprietary functions of openjpa.
If that we introduce specific/proprietary annotations such as @Index a
bit everywhere, the above logic does not make much sense anymore.
For example,
Hi,
4. The majority of the classes will use openjpa classes: instead of
moving them all to org.apache.james.imap.jpa.mail.model.openjpa package,
we leave them and we rename this package to
org.apache.james.imap.jpa.mail.model.streaming to reflect that it goes
on streaming the blobs.
With
Hi Tim,
If we set streaming by default, we can not use derby anymore as default.
With a different provider, schema may be different.
Do you mean we should ensure with specific annotations that schema will
always be the same?
Tks,
Eric
On 06/24/2010 10:31 PM, Tim-Christian Mundt wrote:
14 matches
Mail list logo
