james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: JPA for imap 0.1 release
Date Sun, 11 Jul 2010 17:45:34 GMT
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<dev@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-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


Mime
View raw message