Hi,
+1 (Google style ;-) for Michael's input.
If the base type was just called criteria it doesn't matter, if the concrete ones are called CriteriaUpdate/CriteriaDelete or the other way round, but if the pefix (AbstractCriteria) was preferred, I would rather call those
UpdateCriteria and DeleteCriteria for consistency.
Kind Regards,
Werner
----- Original Message -----
From: Michael Bouschen
To: jsr338-experts_at_jpa-spec.java.net
Sent: Monday, April 04, 2011 2:05 AM
Subject: [jsr338-experts] Re: criteria API bulk update/delete
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
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