|RE: [eclipselink-users] SQL emitted by EclipseLink is searchingforan object with a null primary key|
Morning James, The Visit class bears the @OptimisticLocking(cascade=true) annotation, and we get the same statement executed if the cascade attribute is instead set to false. Also, the ManyToOne back reference from Service to Visit has been set. I have created EclipseLink defect 264406 per your request. Thanks, Doug -----Original Message----- From: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of James Sutherland Sent: Tuesday, February 10, 2009 5:33 AM To: eclipselink-users@xxxxxxxxxxx Subject: RE: [eclipselink-users] SQL emitted by EclipseLink is searchingforan object with a null primary key >From the stack the query is being executed by the cascaded locking policy, I assume you are using cascaded locking on the new Visit which is privately owned by the new Service? Did you set the ManyToOne back reference, as it seems to be null? It seems odd that it would be trying to query for the parent, especially for a new object, so might be good to log a bug for this, as the code does not seem correct. Include this post in the bug. >>> RE: SQL emitted by EclipseLink is searching foran object with a null primary key Click to flag this post by Gschwind, Doug Feb 09, 2009; 01:20pm :: Rate this Message: (use ratings to moderate[?]) Reply | Reply to Author | Delete | Show Only this Message Hi James, Sure, let me give you a little more context. The relevant domain model classes for this use case are : Chart, Visit, and Service (and subclasses of Service). There is a OneToMany from Chart to Visit, a ManyToOne from Visit to Chart, a OneToMany from Visit to Service, and a ManyToOne from Service to Visit, that are all JPA mapped. In this use case, we are simply trying to create a new Service instance and make it persistent, stitching up all of the appropriate relationships prior to attempting to persist. Also, the Chart instance is already persistent. I believe we are also going to persist a Visit as part of creating a new Service in my test case. Attached you will find the standard output stream from OC4J, with the EclipseLink logging level set to FINEST. Additionally, I used the StackDumpingPerformanceProfiler (a specialization of EclipseLink's PerformanceProfiler provided to us by Randy Stafford) to help see the stack trace that caused the query to be executed. On line 7390 in the output you will see the odd select statement of the form, SELECT * from SERVICE where SVCID = null. If you then look on line 7399, you can trace the cause of that SQL statement to where in our code we call EntityManager.flush(). Let me know if I can provide you some more info. Thanks, Doug ----- --- http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland http://www.eclipse.org/eclipselink/ EclipseLink , http://www.oracle.com/technology/products/ias/toplink/ TopLink Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink , http://wiki.oracle.com/page/TopLink TopLink Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , http://www.nabble.com/EclipseLink-f26430.html EclipseLink Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence -- View this message in context: http://www.nabble.com/SQL-emitted-by-EclipseLink-is-searching-for-an-obj ect-with-a-null-primary-key-tp21881456p21933675.html Sent from the EclipseLink - Users mailing list archive at Nabble.com. _______________________________________________ eclipselink-users mailing list eclipselink-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-users The contents of this electronic mail message and any attachments are confidential, possibly privileged and intended for the addressee(s) only. Only the addressee(s) may read, disseminate, retain or otherwise use this message. If received in error, please immediately inform the sender and then delete this message without disclosing its contents to anyone.
Back to the top