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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
