From server-dev-return-38654-apmail-james-server-dev-archive=james.apache.org@james.apache.org Sun Jul 11 17:47:02 2010 Return-Path: Delivered-To: apmail-james-server-dev-archive@www.apache.org Received: (qmail 6100 invoked from network); 11 Jul 2010 17:47:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 11 Jul 2010 17:47:02 -0000 Received: (qmail 36803 invoked by uid 500); 11 Jul 2010 17:47:02 -0000 Delivered-To: apmail-james-server-dev-archive@james.apache.org Received: (qmail 36741 invoked by uid 500); 11 Jul 2010 17:47:01 -0000 Mailing-List: contact server-dev-help@james.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "James Developers List" Reply-To: "James Developers List" Delivered-To: mailing list server-dev@james.apache.org Received: (qmail 36729 invoked by uid 99); 11 Jul 2010 17:47:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Jul 2010 17:47:01 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [195.238.6.173] (HELO mailrelay007.isp.belgacom.be) (195.238.6.173) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Jul 2010 17:46:54 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAISfOUxbssw3/2dsb2JhbAAHgxbJTo97gSmDDHIEiEw Received: from 55.204-178-91.adsl-dyn.isp.belgacom.be (HELO [192.168.1.11]) ([91.178.204.55]) by relay.skynet.be with ESMTP; 11 Jul 2010 19:45:34 +0200 Message-ID: <4C3A033E.2080906@apache.org> Date: Sun, 11 Jul 2010 19:45:34 +0200 From: Eric Charles User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100322 Thunderbird/3.0.3 MIME-Version: 1.0 To: James Developers List Subject: Re: JPA for imap 0.1 release References: <4C23A56D.6010705@apache.org> <978714038.41270.1277411566899.JavaMail.root@srv001> <4C241F79.2070003@u-mangate.com> <1490798762.46762.1277454749782.JavaMail.root@srv001> <4C24CE8F.6010702@apache.org> <1277483637.4151.82.camel@TimPad> <1035337509.58965.1277540324796.JavaMail.root@srv001> <4C39B684.3000609@apache.org> <936339849.8963.1278853992052.JavaMail.root@srv001> In-Reply-To: <936339849.8963.1278853992052.JavaMail.root@srv001> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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: >>>> >>>> >>>>> 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-unsubscribe@james.apache.org >>>>> For additional commands, e-mail: server-dev-help@james.apache.org >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org >>>> For additional commands, e-mail: server-dev-help@james.apache.org >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org >>> For additional commands, e-mail: server-dev-help@james.apache.org >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org >> For additional commands, e-mail: server-dev-help@james.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org > For additional commands, e-mail: server-dev-help@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org For additional commands, e-mail: server-dev-help@james.apache.org