james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@u-mangate.com>
Subject Re: [IMAP] Cut a milestone ?
Date Thu, 17 Jun 2010 21:33:31 GMT
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 
As soon as you apply on JPAProperty and JPAHeader, it hangs.

Still looking for.


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
>> 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 
> 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

View raw message