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