Answers.Body: <p>The API is largely metadata-driven, and whether an API field is joinable is <em>usually</em> determined by the data returned by that entity's <code>getfields</code> API action.  If you look in <code>&lt;civiroot&gt;/templates/CRM/Admin/Page/APIExplorer.js</code> at the <code>renderJoinSelector()</code> function you'll see the logic.</p>
  
  <p>However, right at the top of that function there's a reference to the const <code>NO_JOINS</code>.  Right up at the top of that file, you'll see:</p>
  
  <pre><code>// The following apis do not use Api3SelectQuery so do not support advanced features like joins or OR
  NO_JOINS = ['Contact', 'Contribution', 'Pledge', 'Participant'],
  </code></pre>
  
  <p>These sorts of quirky APIs are exactly the sort of thing that APIv4 is intended to eliminate.  It's no coincidence that the Participant entity is the first one slated to be released under APIv4.  It's quirky and it shouldn't be, but changing the behavior would break the API contract not to change on some extension author.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-06T23:09:11.687Z
Answers.LastActivityDate: 2017-05-06T23:09:11.687Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>If I go to the API explorer and select <code>ContributionSoft</code> as the entity, I see options to enable joining. But I don't see any joining options available for other entities like <code>Contribution</code> and <code>Participation</code>. Why? I would expect expect that a join automatically becomes possible any time a foreign key exists, and also becomes possible in some other special circumstances (e.g. option value).</p>
  
  <p>Is it <em>really</em> the case that joining is only available on some entities?</p>
  
  <ul>
  <li>If so, what is the logic behind which entities offer joining? </li>
  <li>If not, I would like to understand, as an example, how I can execute an API call on <code>Participation</code> which joins <code>Event</code>.</li>
  </ul>
  
Tags: <api><developer>
Title: Under what circumstances is API joining available?
ThreadText: # Under what circumstances is API joining available?
  
  (Asked by: username_0 on 2017-03-29)
  
  If I go to the API explorer and select `ContributionSoft` as the entity, I see options to enable joining. But I don't see any joining options available for other entities like `Contribution` and `Participation`. Why? I would expect expect that a join automatically becomes possible any time a foreign key exists, and also becomes possible in some other special circumstances (e.g. option value).
  
  Is it *really* the case that joining is only available on some entities?
  
  * If so, what is the logic behind which entities offer joining?
  * If not, I would like to understand, as an example, how I can execute an API call on `Participation` which joins `Event`.
  
  **Tags:** api, developer
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-05-06. Score: 1
  
  The API is largely metadata-driven, and whether an API field is joinable is *usually* determined by the data returned by that entity's `getfields` API action. If you look in `<civiroot>/templates/CRM/Admin/Page/APIExplorer.js` at the `renderJoinSelector()` function you'll see the logic.
  
  However, right at the top of that function there's a reference to the const `NO_JOINS`. Right up at the top of that file, you'll see:
  
  ```
  // The following apis do not use Api3SelectQuery so do not support advanced features like joins or OR
  NO_JOINS = ['Contact', 'Contribution', 'Pledge', 'Participant'],
  
  ```
  
  These sorts of quirky APIs are exactly the sort of thing that APIv4 is intended to eliminate. It's no coincidence that the Participant entity is the first one slated to be released under APIv4. It's quirky and it shouldn't be, but changing the behavior would break the API contract not to change on some extension author.
  
  
  ---
  
  