I am not entirely clear about the use case we are trying to address.
1. Having the ability to programmatically define named queries at EMF initialization time
2. Having the ability to programmatically define named queries and add them dynamically during the life time of the EMF (ie after the EMF has been created)
I can see the reason to address 1. I have not found a use case for 2., someone has something in mind?
If we want to resolve 1. I'd prefer an approach like Gordon was hinting at.
We could let people pass to the persistence unit configuration a class name whose responsibility is to create these named queries programamtically
interface QueryConfigurator {
void defineNamedQueries(QueryManager qm);
}
interface QueryManager {
CriteriaBuilder getCriteriaBuilder();
Query createQuery(String qlString);
...
QueryManager addNamedQuery(String name, TypedQuery<T> query);
}
//user class
class MyAppQueriesDefinition implements QueryConfigurator {
//no arg constructor required
public void defineNamedQueries(QueryManager qm) {
TypedQuery<Integer> tq = qm.createQuery("SELECT e.seniority FROM Employee e WHERE e.seniority > 10", Integer.class);
qm.addNamedQuery("Employee_Seniority", tq);
//build Criteria query
TypedQuery<Integer> tq2 = qm.createQuery(criteriaQuery);
tq2.setMaxResults(20);
qm.addNamedQuery("get_top_20_chefs", tq2);
}
}
//user persistence.xml
<persistence-unit ...>
...
<properties>
<property name="javax.persistence.query.queryConfigurator" value="com.acme. MyAppQueriesDefinition"/>
</properties>
</persistence-unit>
Also if we end up working on a fluent API to programmatically define a persistence unit, this could fit in as well as part of a more general purpose way to programmatically customize configuration.
Emmanuel
On 12 avr. 2011, at 20:43, Linda DeMichiel wrote:
> 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