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 Wed, 16 Jun 2010 17:42:13 GMT
Hi Tim,

I'm a big fan of autoincrement pk columns per table. Each table has its 
own responsiblity, and keys are generated sequentially per table.
This gives however requirements when you migrate via export/import to 
fresh database. For example, with Derby, the schema is create with 
GENERATED ALWAYS columns and not GENERATED BY DEFAULT. You will have 
issues on fk constraints even if you apply the procedure described in 
http://db.apache.org/derby/docs/dev/tools/ctoolsimportidentitycol.html.
The current solution uses a pool of 100 keys in memory, and access to 
database is limited.
We could also define a key-generation-table per table, but I find this 
overkill.
I would tend to think to leave it like it is.

For the direct @OneToMany, we have issues when implemented in James even 
if this samples show that it should be correct. Strange...
You said "JPA 2.0 defines a way to define the association only in the 
parent (*Message)": Can you send me a working sample?

One more point is the sql generated. The logs show jpql, and not sql.
Do you know if it's possible to view the sql in the logs (I didn't find 
a way).
If not possible, can you log on the database (mysql I think you use)?
On my side, I could analyse the derby queryplan and see if we would gain 
something without intermediate table.

Tks,

Eric


On 06/16/2010 08:37 AM, Tim-Christian Mundt wrote:
> Hi Eric,
>
>> You will find attached (removed from ml, so bcc to you):
> seems like attachments are not stripped via ML, both emails here have 
> the patch attached.
>> I have to define the OneToMany on the concrete class (the JPAMessage).
> Yes, that's what I tried then. If this is done without changing 
> JPAHeader/JPAProperty it should be ok, right?
>> I spent hours trying to solve this without success.
> I can see that from the time you sent this mail... oh boy, that's 
> late/early.
>> One more point: for the insert to work, you need to add <property 
>> name="openjpa.InverseManager" value="true"/> in persistence.xml (not 
>> in the patch)
> Is this still standard JPA? Just asking because if so, why would we 
> need an extra option?
>> Currently, the patch still gives issues when reading mails (null 
>> pointer on the properties list).
> Apparently, although the tables are created they are not used. Weird.
>> Even if we solve these last points, we will remain with another issue...
>> Indeed, in the sample, the type of the MayToOne needs to be a 
>> concrete class, otherwise openjpa complains.
>> This means that you would be obliged in the Property to link to 
>> JPAMessage or JPAStreamingMessage. You can't link to AbstractJPAMessage.
> JPA 2.0 defines a way to define the association only in the parent 
> (*Message). Then that would be ok. Although it's still strange that it 
> works in your tests but not in James (also not for me).
>> About the pk creation, I will reply a bit later.
> I reconsidered this issue and I think we should switch to 
> "Strategy.IDENTITY" => autoincrement because that would allow other 
> systems and implementations to work with this database without messing 
> with the sequence table. Moreover, it's faster.
>
> Thanks for the files. Will check them out tonight.
>
> 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


Mime
View raw message