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