Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Adding on to Todd's reply, to clarify a few things.</p> <ul> <li><p>A &lt;join&gt; tag on a 1-1 relation means nothing. Well it could be interpreted as saying "create a join table to store this relationship", but then DataNucleus doesn't support such a concept since best practice is to use a FK in either owner or related table. So remove the &lt;join&gt;</p></li> <li><p>A "table" on a 1-1 relation suggest that it is stored in a secondary table, yet you don't want that either, so remove it.</p></li> <li><p>You retrieve Position objects, so it issues something like</p></li> </ul> <pre>SELECT 'org.datanucleus.test.Position' AS NUCLEUS_TYPE,A0.ID,A0.TITLE FROM "POSITION" A0</pre> <ul> <li>You retrieve Employee objects, so it issues something like</li> </ul> <pre>SELECT 'org.datanucleus.test.Employee' AS NUCLEUS_TYPE,A0.ID,A0."NAME" FROM EMPLOYEE A0</pre> <p>Note that it doesn't retrieve the FK for the position here since that field is not in the default fetch group (lazy loaded)</p> <ul> <li>You access the position field of an Employee object, so it needs the FK retrieving (since it doesn't know which Position object relates to this Employee), so it issues</li> </ul> <pre>SELECT A0.POSITION_ID,B0.ID,B0.TITLE FROM EMPLOYEE A0 LEFT OUTER JOIN "POSITION" B0 ON A0.POSITION_ID = B0.ID WHERE A0.ID = ?</pre> <p>At this point it doesn't need to retrieve the Position object since it is already present (in the cache), so that object is returned.</p> <p>All of this is expected behaviour IMHO. You could put the "position" field of Employee into its default fetch group and that FK would be retrieved in step 4, hence removing one SQL call.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload