Hi,
please find my comments inline ...
> Hi Rainer, all,
>
> Please see more below.
>
> On 4/1/2011 6:50 AM, Rainer Kwesi Schweigkoffer wrote:
>> Hi Linda, all,
>>
>> Linda DeMichiel, am 28 Mar 2011 hast Du um 11:53 zum Thema
>> "[jsr338-experts] criteria API bulk update/delete" geschrieben :
>>
>>> There are 3 new interfaces, which I've attached to the message:
>>> UpdateQuery
>>> DeleteQuery
>>> CommonAbstractQuery
>>
>> With respect to naming I had originally thought of something like
>> CommonAbstractQuery -> Statement
>> UpdateQuery -> UpdateStatement
>> DeleteQuery -> DeleteStatement,
>> but the proposal of CriteriaUpdate and CriteriaDelete sounds much
>> better to me. I'd just replace the CommonCriteria by AbstractCriteria
>> or drop the prefix at all.
>>
>
> ok, thanks.
I like the names CriteriaUpdate, CriteriaDelete and AbstractCriteria.
>
>>> reuse Root. In the end, I decided to reuse Root, because of the
>>> extensions that many databases provide to support joins. In this
>>> case, the joined item is not itself updatable, but is used in the
>>> expression of constraints or as a source of new values. However, we
>>> will need to decide exactly what we state in terms of what is
>>> "defined" vs "undefined" in the spec. Probably the most conservative
>>> statement would be to state that the use of more than one root and/or
>>> the use of joins is undefined.
>>
>> Sounds reasonable to me.
>>
>>> And the EntityManager interface would be extended with methods like:
>>>
>>> public <T> TypedQuery createQuery(UpdateQuery<T> updateQuery)
>>> public <T> TypedQuery createQuery(DeleteQuery<T> deleteQuery)
>>
>> Well, what I am not perfectly happy with by now and what made me
>> hesitate to respond since I haven't found a convincing solution for
>> it yet, is the way typing is done.
>>
>> If we look at the AbstractQuery branch of the interface hierarchy we
>> see that the type of the Query reflects the type of its result, which
>> may differ from any of the roots.
>>
>> On the CriteriaDelete/CriteriaUpdate side the type of the respective
>> interface denotes the type of the root. I see that, particularly for
>> CriteriaUpdate, this is rather useful. And it makes perfectly sense
>> since we don't have a result.
>>
>> It's just that I am wondering if the difference was made clearer by
>> introducing an additional interface AbstractModification (name to be
>> discussed) between CriteriaDelete/CriteriaUpdate and AbstractCriteria
>> housing the getRoot() method. Thus, we could javadoc <T> in
>> AbstractQuery as "for an AbstractQuery the type of the criteria is
>> the type of its result" and resp. in AbstractModification as "for an
>> AbstractModification the type of the criteria is the type of its
>> root" (referring to the corresponding javadoc of AbstractCriteria
>> where I would change query to criteria then).
>>
>
> Hmmmm.... I'm wondering if this is worth another interface, or whether
> we should just be more explicit in the existing and proposed interfaces.
> More feedback, please.....
Maybe it's not worth another interface.
However, Rainer's analysis is correct that the type parameter <T> is has
a different semantics compared to AbstractQuery, so we need to document
this in CriteriaUpdate and CriteriaDelete.
>
>> Concerning the createQuery methods of the EntityManager I find the
>> notion of an untyped TypedQuery as a return value a bit strange, and
>> I am therefore pondering whether to prefer an old-fasshioned Query
>> instead.
>>
>
> I see your point. I don't have strong feelings either way.
> Other opinions on this point too, please!
I agree with Rainer and and would vote for createQuery returning a Query
instance instead of an untyped TypedQuery instance.
Regards Michael
>
> best regards,
>
> -Linda
>
>> Best regards
>> Rainer
>>
>>
--
*Michael Bouschen*
*Prokurist*
akquinet tech_at_spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen_at_akquinet.de
Url: www.akquinet.de <http://www.akquinet.de>
akquinet tech_at_spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680