We might not agree then, but let's see what comes up when we work deeper on this feature and its use cases :)
On 9 mai 2011, at 16:37, Gordon Yorke wrote:
> Yes, preCreate is the wrong name but it would be better if the events provided access to the EMF instead of introducing another interface. Perhaps "preInitialize" or "preConnect" ?
> --Gordon
>
> Emmanuel Bernard wrote:
>>
>> Yes, I think we would be better off with a generic approach like that. Except that preCreate can't accept an EMF, as we have not created it yet :) The required contracts would be better placed on a builder / configuration interface. This will give us freedom to add new modification opportunities over time.
>>
>> On 2 mai 2011, at 13:10, Gordon Yorke wrote:
>>
>>
>>> If we go with initialization events everyone would be best served by preCreate/postCreate events that are generic and offer a bit more flexibility for the users.
>>>
>>> public interface EntityMangerFactoryCustomizer (
>>> void preCreate(EntityManagerFactory emf);
>>> void postCreate(EntityManagerFactory emf);
>>> }
>>>
>>> --Gordon
>>>
>>> Emmanuel Bernard wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>
>>