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. 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 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.
Depending on the result and timing, we may integrate the changes in our
upcoming 3.0 M1 release.
I will also need to upgrade the current database schema and datas.
Probably the number of users that need this migration is very limited
(only users running a 3.0 trunk built snapshot).
However, we could use it as a base for the latter migrations and also
for the 2.3 to 3.0 migration.
I will look if an existing JIRA or create a new one to publish the progress.
Tks,
Eric
On 06/26/2010 10:17 AM, Tim-Christian Mundt wrote:
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 there merely to support the "useStreaming" option, if I
don't err. The former is also for streaming, so yes, it would make sense
to rename it. On the other hand we could move all OpenJPA stuff
to /jpa/openjpa which would basically mean to e.g. put the streaming
classes into
org/apache/james/imap/jpa/openjpa/mail/model/streaming
If everything with proprietary OpenJPA annotations would be in a
separate package it would become immediate which classes one needs to
implement in order to create a new provider. That's my vote: stick with
OpenJPA but still cleanly separate it from standards conforming code.
Eric, could you send us a patch of what you've done so far? Then we can
finish it (hope you still read this before your trip...)
Tim
Am Freitag, den 25.06.2010, 19:33 +0200 schrieb Norman Maurer:
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 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 have a streaming package and there is both streaming and
non-streaming for OpenJPA, so why rename the package? Maybe I haven't
fully understood your point.
I will be off for 2 weeks and won't probably be able to continue the
conversation.
Hope I may say "Happy vacations" :)
Best
Tim
---------------------------------------------------------------------
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
