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?
> We could also define a key-generation-table per table, but I find this > overkill. I agree, that's too much. > 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? > 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? > 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". > 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 :) > If not possible, can you log on the database (mysql I think you use)? MySQL provides logs for all operations, yes. I noticed a small issue with your patch: You have to use "message_id" instead of "id" for the name of the @JoinColumn. 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? Best, Tim --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
