I also think Subquery#getParent should work if the parent is a
CriteriaUpdate/CriteriaDelete. Couldn't Subquery#getParent just return
Query?
Sure, but AbstractQuery also defines `public Set<Root<?>> getRoots()`
which is a total misnomer in the case of CriteriaUpdate/CriteriaDelete.
I think a new base contract would be better, though not totally
backwards compatible.
On Mon 25 Jun 2012 02:09:13 PM CDT, Linda DeMichiel wrote:
> Hi Steve, all,
>
> Steve, thanks for pointing this problem out -- good catch.
>
> On 6/24/2012 8:31 AM, Steve Ebersole wrote:
>> In implementing theses, I ran into 2 questions:
>>
>> 1) In terms of a Subquery associated with a
>> CriteriaUpdate/CriteriaDelete, what should be the return for the
>> Subquery#getParent which is defined to return an AbstractQuery which
>> neither CriteriaUpdate/CriteriaDelete implement.
>>
>
> If Subquery#getParent is going to work (which I think it needs to),
> then I think we are
> back to CriteriaUpdate/CriteriaDelete having to extend AbstractQuery.
>
>> 2) Seems to me we duplicate the effort to define the Root here; 2
>> calls when one would suffice. First users pass the
>> entity class to be updated/deleted to the CriteriaBuilder method,
>> then they have to call one of the from() methods on
>> CriteriaUpdate/CriteriaDelete. But unless I miss something the actual
>> "entity type" of the from argument has to be the
>> same as the one passed to CriteriaBuilder. Long story short, seems to
>> me that we could simply do away with the from()
>> methods and remove the need for the user to call the second method.
>
> If CriteriaUpdate/CriteriaDelete need to extend AbstractQuery, then I
> think this becomes a moot point,
> as from() is defined there.
>
> -Linda
>