jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: named queries

From: Gordon Yorke <gordon.yorke_at_oracle.com>
Date: Wed, 13 Apr 2011 09:54:41 -0300

The best choice is to have the API only on the EntityManagerFactory.
The intentions of this method is to allow for creation of NamedQueries
during runtime initialization (ie NamedQueries using the Criteria API)
and limiting the API to the EntityManagerFactory loosely implies that
intention.
--Gordon

Linda DeMichiel wrote:
> Hi Evan,
>
> The intention was that these queries (like other named queries) were
> scoped to the persistence unit, so the EntityManagerFactory seemed a
> logical place. However, we could also add a method to the EntityManager
> interface for convenience. Otherwise, the getEntityManagerFactory method
> of the EntityManager interface could be used to gain access to the
> EMF from an entity manager instance.
>
> What do you think?
>
> regards,
>
> -Linda
>
> On 4/12/2011 1:41 PM, Evan Ireland wrote:
>> Linda,
>>
>> Why is this proposed to be on the EntityManagerFactory, and not the
>> EntityManager?
>>
>> If I use an injected EntityManager, will this feature be useful?
>>> -----Original Message-----
>>> From: Linda DeMichiel [mailto:linda.demichiel_at_oracle.com] Sent:
>>> Wednesday, 13 April 2011 6:43 a.m.
>>> To: jsr338-experts_at_jpa-spec.java.net
>>> Subject: [jsr338-experts] named queries
>>>
>>> We've received suggestions to the effect that it would be useful if
>>> queries could be created dynamically (e.g., at initialization time)
>>> and then be assigned names so that they could be used for execution
>>> later.
>>>
>>> These queries would have the same scope as other named queries,
>>> and be associated with the persistence unit.
>>>
>>> For example:
>>>
>>> TypedQuery<Integer> tq = em.createQuery("SELECT e.seniority FROM
>>> Employee e WHERE e.seniority > 10", Integer.class);
>>> emf.addNamedQuery("Employee_Seniority", tq);
>>>
>>> Any configuration of the query object (except for actual parameter
>>> binding) specified when the query was added as a named query would be
>>> retained as part of the named query. [I.e., this would include
>>> configuration information like setMaxResults, setHint, setFlushMode,
>>> setLockMode, result set mapping information, and information
>>> registered about stored procedure parameters...]
>>>
>>> When the query is executed, information that is settable by means
>>> of the Query API can be overridden. Information that is overridden
>>> does not affect the named query as registered with the EMF, and
>>> thus does not affect subsequent Query objects created by means
>>> of the name via the EntityManager createNamedQuery method.
>>>
>>>
>>> Linda
>>>
>>