james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <eric.char...@u-mangate.com>
Subject Re: [IMAP] Cut a milestone ?
Date Sat, 12 Jun 2010 18:16:19 GMT
Hi Tim,

I implemented the standard @OneToMany (not the proprietary extension) 
without intermediary table and the schema is created.
As you described, it hanged the first, but recompiling and relaunching 
made it happen.
I'm working now on an issue when inserting mail (fk is not set). I think 
a few unit tests in the apache-james-imap-jpa will help.
On my side <property name=penjpa.Log" value="SQL=TRACE"/> shows the SQL 
(in fact the JPQL).

Recommendations found on http://openjpa.apache.org/faq.html allow the fk 
to be created.
I finally think the current default pk strategy is the good one.

There is still the decision to take for the MailMembership.
Finally, I don't think we should take the coherence between all stores 
as an argument. For example, storing on file system is completely 
different than storing in DB, than in JCR, than in NoSQL,...
The only reason why we should keep it may be the memory economy when 
listing mails for databases that does not support the streaming.

Tks,

Eric


On 06/11/2010 08:59 AM, Norman Maurer wrote:
> Hi Tim,
>
> comments inside..
>
> 2010/6/10 Tim-Christian Mundt<dev@tim-erwin.de>:
>    
>> Hi,
>>
>> Am Donnerstag, den 10.06.2010, 19:56 +0200 schrieb Norman Maurer:
>>      
>>> After thinking a bit more about it, could it be that the two tables
>>> are used for mapping ? I think that would make sense because we have a
>>> many relation here..
>>>
>>> So one for mapping Message and Properties and one for Message and Header.
>>>        
>> That's true. However, we don't have Many-to-many mappings here, but one
>> to many (as defined in AbstractJPAMessage). So these tables are
>> basically superfluous and causing (little) performance loss. The reason
>> they are created by OpenJPA is that the mappings are unidirectional.
>>      
> You are right.. One-to-Many should not need the "join table".
>    
>> Although we don't need a "message" field in Headers and Properties I
>> think we should introduce it and thus allow for One-To-Many without
>> mapping table. I already tried doing that, adding @JoinColum and
>> "mappedBy" according to the specification:
>> http://java.sun.com/javaee/5/docs/api/javax/persistence/OneToMany.html
>>
>> However, when mappedBy=essage" is added to the AbstractJPAMessage then
>> OpenJPA hangs without any error output (despite<property
>> name=penjpa.Log" value="SQL=TRACE"/>) and the tables won't get
>> created. If put into JPAMessage (overriding the field) the tables get
>> created as usual simply with the addition of a join column (in Header).
>> I guess it has to do with the inheritance. Any idea? Otherwise I'd ask
>> on some OpenJPA mailing list.
>>      
> Askin on the OpenJPA mailing list would be a good idea..
>
>    
>> Besides that there is a proprietary solution for OpenJPA:
>>     @OneToMany(cascade =ascadeType.ALL, fetchþtchType.LAZY)
>>     @ElementJoinColumn(name=essage_id", referencedColumnName="id")
>>     private List<JPAHeader>  headers;
>>
>> This fixes the issue but is non-standard. Other framworks like jpox also
>> have such options if I don't err.
>>      
> If nothing helps we could move the mapping stuff to the OpenJPA*
> classes, but I think it should be possible with using plain "JPA".
>
>
>    
>> Tim
>>
>>      
> Bye,
> Norman
>
> ---------------------------------------------------------------------
> 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