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.
>> 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.....
> 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!
best regards,
-Linda
> Best regards
> Rainer
>
>