openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@apache.org>
Subject Re: my report regarding MethodQL in the user list
Date Fri, 06 Mar 2009 09:09:06 GMT

> yes, that works!
cool.

> Looks like one need to be famillar with internal API stuff :) 

Yes, few things can be improved around that region. I have not looked at it
before you filed the JIRA:)
Actually the notion of MethodQL is powerful because the user's Java target
method M can really play havoc as it has been passed all sorts of internal
data structures. 
The return value of the target method has to remain as a
ResultObjectProvider (ROP) because everything else expects a ROP. However,
these ROPs often get wrapped multiple times before being returned to the
user -- we can reduce the wrapping for MethodQL because the user method
exactly knows what is it returning as result. 
Please see the test case in the recent commit about how the result is
unwrapped in the user application.

I have also made setting of a candidate class optional for MethodQL.

The parameter declaration can also be made optional -- because the type of a
parameter X can be inferred when the user is setting the value of X.
Actually, the normal query pathway does a lot to validate parameter values
-- but that does not seem to be appropriate/necessary for MethodQL case --
the parameters can be opaque to OpenJPA runtime because they are just passed
through to the user method in a Map.    



Marc Logemann wrote:
> 
> Hi,
> 
> yes, that works!
> 
> Grrrr. Why do i have not seen this method in QueryImpl. But should it  
> work this way for users in the long run? Looks like one need to be  
> famillar with internal API stuff :) Shouldnt we trigger this somewhere  
> at the getResultSet() call, or perhaps even better in the  
> setParameter() call of the public Query API ?
> 
> 
> Marc
> 
> Am 06.03.2009 um 01:21 schrieb Pinaki Poddar:
> 
>>
>> Hi,
>>  Add the extra lines, see if that changes anything:
>>
>>        OpenJPAEntityManager oem = OpenJPAPersistence.cast(em);
>>        OpenJPAQuery query = oem.createQuery("openjpa.MethodQL",
>> "some.full.cls.method");
>>        query.setResultClass(MyResultType.class);
>> +      ((org.apache.openjpa.persistence.QueryImpl)query).getDelegate()
>> +         .declareParameters("String firstName, String lastName");
>>        query.setParameter(1, "Fred").setParameter(2, "Lucas");
>>
>>
>>
>> Marc Logemann wrote:
>>>
>>> Hi,
>>>
>>> i created a Jira for the  issue explained in the user list:
>>> https://issues.apache.org/jira/browse/OPENJPA-955
>>>
>>> I debugged about an hour or something and put my findings into the
>>> jira issue. Quite complex stuff with all the delegates, so i wasnt
>>> able to fix it.... perhaps someone else is good in that code "area".
>>>
>>> Marc
>>>
>>
>> -- 
>> View this message in context:
>> http://n2.nabble.com/my-report-regarding-MethodQL-in-the-user-list-tp2430597p2433186.html
>> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>>
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/my-report-regarding-MethodQL-in-the-user-list-tp2430597p2434636.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.


Mime
View raw message