You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Marc Logemann <li...@logemann.org> on 2009/03/05 17:44:34 UTC
my report regarding MethodQL in the user list
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
Re: my report regarding MethodQL in the user list
Posted by Marc Logemann <li...@logemann.org>.
> 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.
Will take a look. I only checked if the parameter arrives at my user
method so far (so much other stuff to migrate from my Kodo3 codebase
like custom field mappings and stuff) . So i have not played with ROP
but i hope this object ist not THAT voodoo to get the real results of
it :) But i will check the test case.....
>
> 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.
Thats what i actually thought when you provide me with the internal
API call. Why supplying it, openJPA could know it from setParameter()
on the Query. I tried to find a fix for exactly this, so that you dont
need to do anything, but to be honest, i was not able to figure out
all the inner workings in that area within 1-2 hours. And of course i
dont have a running openJPA build system for testing.
Marc
Re: my report regarding MethodQL in the user list
Posted by Pinaki Poddar <pp...@apache.org>.
> 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.
Re: my report regarding MethodQL in the user list
Posted by Marc Logemann <li...@logemann.org>.
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.
>
Re: my report regarding MethodQL in the user list
Posted by Pinaki Poddar <pp...@apache.org>.
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.