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: [IMAP] Cut a milestone ?
Date Mon, 21 Jun 2010 18:51:09 GMT
Hi, that's me again,

I just posted some questions on openjpa ml.

If we want to keep JPAStreamingMessage without intermediary tables, we 
may use the proprietary @ElementJoinColumn annotation.
For other features, such as index creation, we also probably need 
proprietary annotations.

For example, the current "findUnseenMessagesInMailboxOrderByUid"
"SELECT membership FROM Membership membership WHERE membership.mailboxId 
= :idParam AND membership.seen = FALSE ORDER BY membership.uid ASC"
could benefit from
@Index @Id private long uid;
@Index @Id private long mailboxId;

So the questions is "Should we use those openjpa annotations?".
I personally don't see why we couldn't.
What do you think of?

Btw, I think the original question was "Cut a milestone ?"... :)

Tks,

Eric

PS: Better use the apache-james-imap-jpa-0.1-M2-SNAPSHOT.jar enhanced 
via maven in eclipse. If you use the project class folder, the 
enhancement is not always as "it should". Many problems during dev comes 
from eclipse (or whatever) does not  enhance, or take the previous 
enhancement... F5 is also your friend.


On 06/17/2010 11:33 PM, Eric Charles wrote:
> Hi Tim,
>
> Sorry, "message_id" was indeed needed in the patch, otherwise you've 
> got a id column which is pk and fk.
> I still made some additional tests, and omitting the @JoinColumn also 
> works.
> DB is created and mail delivery is correctly working when you apply on 
> JPAProperty.
> As soon as you apply on JPAProperty and JPAHeader, it hangs.
>
> Still looking for.
> Bye,
>
> Eric
>
>
> On 06/17/2010 08:26 AM, Eric Charles wrote:
>> Hi Tim,
>> Comments inside.
>> Tks,
>> Eric
>>
>> On 06/17/2010 12:58 AM, Tim-Christian Mundt wrote:
>>> Hey Eric,
>>>
>>>> For example, with Derby, the schema is create with
>>>> GENERATED ALWAYS columns and not GENERATED BY DEFAULT.
>>> Why's that? Wouldn't GENERATED BY DEFAULT solve this problem so we 
>>> could
>>> happily use autoincrements?
>>>
>> GENERATED BY DEFAULT would help, but openjpa create with GENERATED 
>> ALWAYS.
>> Moreover, when you recreate your database, you need to define a START 
>> value depending on your last generated key.
>>
>>>> We could also define a key-generation-table per table, but I find this
>>>> overkill.
>>> I agree, that's too much.
>>>
>> OK
>>>> I would tend to think to leave it like it is.
>>> If you consider the issue above really serious, than lets keep it. On
>>> the other hand: nobody would use derby in production, right? Do similar
>>> problems exist with other databases?
>>>
>> I sometimes use derby in production with low-end PCs as servers.
>> Each database has it own way and syntax for managing pk generation, 
>> with its goodness and pitfalls.
>>>> For the direct @OneToMany, we have issues when implemented in James 
>>>> even
>>>> if this samples show that it should be correct. Strange...
>>> On my side something in my dummy project is just odd. Can't get this
>>> running at all. JPA seems to be a bit delicate?
>>>
>> OK
>>>> You said "JPA 2.0 defines a way to define the association only in the
>>>> parent (*Message)": Can you send me a working sample?
>>> As said: I can't really get it working here. I've seen it on this site:
>>> http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Example_of_a_JPA_2.0_unidirectional_OneToMany_relationship_database

>>>
>>> The @JoinColumn is put on the other side using "referencedColumnName".
>>>
>> this sample may be a non working one.
>>>> 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).
>>> No, idea, sorry. I'm happy with jpql :)
>>>
>> OK.
>> Was just curious to see the generated sql that can show if the 
>> database queries are efficient or not.
>>>> If not possible, can you log on the database (mysql I think you use)?
>>> MySQL provides logs for all operations, yes.
>>>
>> Will try to get these from derby.
>>> I noticed a small issue with your patch: You have to use "message_id"
>>> instead of "id" for the name of the @JoinColumn.
>>>
>> Patch was working on my side with tables and fk created
>> Strange, but I think to remember it was working with both (id and 
>> message_id)
>>> Lets ask on the OpenJPA ML how to make OpenJPA use the relationship.
>>> Maybe they can even have a look at our concrete issue with James. Will
>>> you ask? Should I?
>>>
>> I will post something in the coming days.
>> But it is working as designed with the samples. They may say it is in 
>> the way we are using it. Maybe someone will take time to help us 
>> solve it.
>> On the other hand, I'm not sure it is an issue to leave those 
>> intermediary table and I don't think it should be a blocker for the 
>> release.
>>> 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


Mime
View raw message