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.
> 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).
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.
Best regards
Rainer