JPA EntityManager: 'find' vs. 'createQuery' and 'getResultList'
<p>I'm working on a legacy code base that uses JPA (not JPA-2), and have come across the following method in a DAO implementation class to retrieve a single entity by ID (which is also it's primary key):</p>

<pre><code>public EmailTemplate findEmailTemplateById(long id) {

    LOG.debug("Entering findEmailTemplateById(id='" + id + "')");
    // Construct JPQL query       
    String queryString = "SELECT a FROM EmailTemplate a " +
            "WHERE templateId = :templateId";
    Query query = entityManager.createQuery(queryString);

    query.setParameter("templateId", id);

    LOG.debug("Using query " + queryString);

    List&lt;EmailTemplate&gt; resultList = query.getResultList();

    LOG.debug("Exiting findEmailTemplateByName(id='" + id + "') results size " + resultList.size() + " ( returns null if 0 )");

    if (resultList.isEmpty() || resultList.size() == 0) {
        return null;
    } else {
        return resultList.get(0);
    }

}
</code></pre>

<p>I now need to write a similar DAO class for a different entity, and my method to find the entity by it's primary key looks a lot simpler! :</p>

<pre><code>@Override
public EmailTemplateEdit findEmailTemplateEditById(long id) {
    LOG.debug("Entering findEmailTemplateEditById(id={})", id);
    return entityManager.find(EmailTemplateEdit.class, id);
}
</code></pre>

<p>The original author is not around to ask, so I'm wondering if anyone can suggest reasons as to why he constructed a JPQL query rather than simply using <code>EntityManager#find(Class&lt;T&gt; entityClass, Object primaryKey)</code>?</p>

<p>The javadoc for the <code>find</code> method says:</p>

<blockquote>
  <p>If the entity instance is contained in the persistence context, it is
  returned from there.</p>
</blockquote>

<p>which suggests some form of caching and/or delayed writes. The javadoc for the <code>createQuery</code> and <code>getResultList</code> methods don't say anything like this.</p>

<p>I am unaware of any business or technical requirement in this application that would preclude caching, or of any issues resulting from stale entities or similar. I will check these with the rest of the project team when available, but I just thought I'd canvas the opinion of the SO community to see if there might be other reasons why a query was constructed and executed instead of simply using <code>find</code></p>

<p>(I've seen this: <a href="https://stackoverflow.com/questions/15704938/when-use-createquery-and-find-methods-of-entitymanager">When use createQuery() and find() methods of EntityManager?</a>. Whilst it answers the question re: difference between createQuery and find, it doesn't answer it in context of finding entities by primary key)</p>

<h3>Updated with additional info</h3>

<p>From looking at the other methods in the original DAO class, it looks like there has been a deliberate/conscious decision to not take advantage of JPA managed objects. As above, the method to find by primary key uses a JPQL query. The method to delete an entity also uses a JPQL query. And the method to update an entity makes a copy of the passed in entity object and calls <code>EntityManager#merge</code> with the copy (thus the copy is a managed object, but is never used or returned from the method)<br>
Weird ....</p>