Re: @ManyToOne not optional -> nullable
Hi Michael, It works exactly as you explained. I didn't spot that difference between optional and nullable before. Thanks. On 13 juil. 2010, at 20:09, Michael Dick wrote: > > Hi Jean-Baptiste, > > I think what you want is > @Column(nullable=false) instead of marking it as optional=false. > > There's some blurring of the lines in OpenJPA, but generally @Column should > be used to indicate database constraints, and the @ManyToOne annotation for > ORM behavior. > > @Column will be used when OpenJPA generates table and to keep track of the > database schema internally. So nullable=false generates a DB constraint when > you use the mapping tool / synchronize mappings. > > The relationship annotations (@MtoO, @MtoM, etc) are used to validate the > contents of an entity at runtime. Optional=false tells OpenJP to make sure > there is a valid entity on the other side of the relationship before > persisting, updating. > > TL;DR : use @Column to indicate database constraints. > > Hope this helps, > -mike > > > > > -- > View this message in context: > http://openjpa.208410.n2.nabble.com/ManyToOne-not-optional-nullable-tp5287827p5288851.html > Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: JPA genereates non-exist id column in the select statement
You can try @PersistentCollection - Original Message From: llchen To: users@openjpa.apache.org Sent: Tue, July 13, 2010 10:22:57 AM Subject: Re: JPA genereates non-exist id column in the select statement Sorry I forgot to mention that I am using JPA 1.0 and therefore I can't use @ElementCollection tag. Lule -- View this message in context: http://openjpa.208410.n2.nabble.com/JPA-genereates-non-exist-id-column-in-the-select-statement-tp5282960p5288555.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: JPA genereates non-exist id column in the select statement
Hi, Making the superclass an embeddable should not prevent it from being subclassed by other entities. Regards, Fay - Original Message From: llchen To: users@openjpa.apache.org Sent: Tue, July 13, 2010 3:42:26 AM Subject: Re: JPA genereates non-exist id column in the select statement Thanks for your suggestion, I will try that embedable option. But that second entity VoVariableData actually is a super class for onother three entities. If I make that one into a embedable, then the other three will not be able to subclass from it. Lule -- View this message in context: http://openjpa.208410.n2.nabble.com/JPA-genereates-non-exist-id-column-in-the-select-statement-tp5282960p5286901.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Are there any tools which will map from Hibernate to OpenJPA XML mapping files?
I don't know of a tool that works from the hbm.xml files directly, but you can use OpenJPA's ReverseMappingTool to generate an orm.xml file and .java files for your entities (ignore these) based on the database. There's a starting point in the manual http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_pc_reverse here . You probably don't need to worry about the customizer stuff, just run SchemaTool -a reflect > someFile.xml followed by ReverseMappingTool someFile.xml. Hope this helps, -mike -- View this message in context: http://openjpa.208410.n2.nabble.com/Are-there-any-tools-which-will-map-from-Hibernate-to-OpenJPA-XML-mapping-files-tp5286969p5288932.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: @ManyToOne not optional -> nullable
Hi Jean-Baptiste, I think what you want is @Column(nullable=false) instead of marking it as optional=false. There's some blurring of the lines in OpenJPA, but generally @Column should be used to indicate database constraints, and the @ManyToOne annotation for ORM behavior. @Column will be used when OpenJPA generates table and to keep track of the database schema internally. So nullable=false generates a DB constraint when you use the mapping tool / synchronize mappings. The relationship annotations (@MtoO, @MtoM, etc) are used to validate the contents of an entity at runtime. Optional=false tells OpenJP to make sure there is a valid entity on the other side of the relationship before persisting, updating. TL;DR : use @Column to indicate database constraints. Hope this helps, -mike -- View this message in context: http://openjpa.208410.n2.nabble.com/ManyToOne-not-optional-nullable-tp5287827p5288851.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: JPA genereates non-exist id column in the select statement
Sorry I forgot to mention that I am using JPA 1.0 and therefore I can't use @ElementCollection tag. Lule -- View this message in context: http://openjpa.208410.n2.nabble.com/JPA-genereates-non-exist-id-column-in-the-select-statement-tp5282960p5288555.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: OpenJPA MySQL performance overhead
Thank you very much for the information! I will test again according to the info you gave me. Idan -- View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-MySQL-performance-overhead-tp5279410p5288087.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: OpenJPA MySQL performance overhead
Also good advice. Here's the link to the ant script (I think this is the right one) : http://openjpa.208410.n2.nabble.com/Ant-based-enhancement-td5065091.html#a5065949 . -mike On Tue, Jul 13, 2010 at 3:52 AM, Jean-Baptiste BRIAUD -- Novlog < j-b.bri...@novlog.com> wrote: > Enhance at build-time, not at run-time. > Search the archive, I gave an ant script to do it. > > I'm not sure what "out of the box" really mean. > I suggest you use high volume data and then an average time so you'll have > the cruise speed only. > I would also ensure any cache is disabled. > > On 13 juil. 2010, at 09:26, idan wrote: > > > > > > Thanks for your reply guys. > > > > I'm using an out of the box configuration + DBCP for > connection/statements > > pooling. > > I'm only measuring the persist/find/remove methods (transaction commit). > > > > The only thing i can think of is that i'm currently using a java agent > for > > enhancing my classes. > > > > Is there a known overhead over plain JDBC for the operations i have > > mentioned? > > > > > > Thanks, > > Idan > > > > > > > > > > > > > > -- > > View this message in context: > http://openjpa.208410.n2.nabble.com/OpenJPA-MySQL-performance-overhead-tp5279410p5286305.html > > Sent from the OpenJPA Users mailing list archive at Nabble.com. > >
Re: OpenJPA MySQL performance overhead
Hi Idan,
I wrote a simple test just for inserts : http://pastebin.com/bbW3RMnp
Results from my laptop :
DBC insert took: 23042
200 idan INFO [main] openjpa.Runtime - Starting OpenJPA 2.0.0
649 idan INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.MySQLDictionary" (MySQL 5.1.37-1ubuntu5.4
,MySQL-AB JDBC Driver mysql-connector-java-5.1.5 ( Revision: ${svn.Revision}
)).
JPA insert took: 36036
So roughly 1.5x for JPA. It's a single connection for JDBC, but I'm using
dbcp with OpenJPA (MaxActive=100,MaxIdle=0,MaxWait=1) and a javaagent to
enhance the entities.
Again this is very simple, but I'm not seeing the 5x degradation you
reported.
If you can post your testcase - maybe focus just on INSERTs that might help.
-mike
On Tue, Jul 13, 2010 at 2:26 AM, idan wrote:
>
> Thanks for your reply guys.
>
> I'm using an out of the box configuration + DBCP for connection/statements
> pooling.
> I'm only measuring the persist/find/remove methods (transaction commit).
>
> The only thing i can think of is that i'm currently using a java agent for
> enhancing my classes.
>
> Is there a known overhead over plain JDBC for the operations i have
> mentioned?
>
>
> Thanks,
> Idan
>
>
>
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/OpenJPA-MySQL-performance-overhead-tp5279410p5286305.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
@ManyToOne not optional -> nullable
Hi, Class A, has one attribute like the following : @ManyToOne(optional = true, cascade = CascadeType.ALL) @JoinColumn(name = "B_ID") private B b = null; Not surprisingly, this is producing, in the table A, a column like the following : B_ID bigint(20) Yes NULL Note that the column is nullable. If I switch optional to false : @ManyToOne(optional = false, cascade = CascadeType.ALL) The generated column is still nullable. Any idea why ? I was waiting for not null join column in the database. Despite that, it's all working fine 100%. In case of a search on A, if optional = false, only A that has B are taken by the request. If I switch back optional to true, all A (with ot without B) are taken into account. So, it look like it works fine but why the column is nullable when optional = false ? Using OpenJPA 2 with MySQL. Thanks !
Re: JPA genereates non-exist id column in the select statement
Thanks for your suggestion, I will try that embedable option. But that second entity VoVariableData actually is a super class for onother three entities. If I make that one into a embedable, then the other three will not be able to subclass from it. Lule -- View this message in context: http://openjpa.208410.n2.nabble.com/JPA-genereates-non-exist-id-column-in-the-select-statement-tp5282960p5286901.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: OpenJPA MySQL performance overhead
Enhance at build-time, not at run-time. Search the archive, I gave an ant script to do it. I'm not sure what "out of the box" really mean. I suggest you use high volume data and then an average time so you'll have the cruise speed only. I would also ensure any cache is disabled. On 13 juil. 2010, at 09:26, idan wrote: > > > Thanks for your reply guys. > > I'm using an out of the box configuration + DBCP for connection/statements > pooling. > I'm only measuring the persist/find/remove methods (transaction commit). > > The only thing i can think of is that i'm currently using a java agent for > enhancing my classes. > > Is there a known overhead over plain JDBC for the operations i have > mentioned? > > > Thanks, > Idan > > > > > > > -- > View this message in context: > http://openjpa.208410.n2.nabble.com/OpenJPA-MySQL-performance-overhead-tp5279410p5286305.html > Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: OpenJPA MySQL performance overhead
Thanks for your reply guys. I'm using an out of the box configuration + DBCP for connection/statements pooling. I'm only measuring the persist/find/remove methods (transaction commit). The only thing i can think of is that i'm currently using a java agent for enhancing my classes. Is there a known overhead over plain JDBC for the operations i have mentioned? Thanks, Idan -- View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-MySQL-performance-overhead-tp5279410p5286305.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
