cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [jira] [Updated] (CAY-1294) Generify query
Date Tue, 18 Dec 2012 08:29:04 GMT
Started using the new API. Very cool! One note - maybe in addition (instead of?) to Cayenne.objectForQuery
we need Cayenne.objectForSelect(..) ?

On Dec 14, 2012, at 10:56 AM, Andrus Adamchik <andrus@objectstyle.org> wrote:

>> The problem with this is that Select<T> is an empty interface, and because
>> ObjectContext* and SelectQuery are in different packages the Select<T>
>> interface must be public.  
> 
> Don't see a problem with that. I was actually thinking of it as public from the beginning.
And it can even extend Query (?). Sorry, I omitted the "public" keyword in the pseudo-code
of the original message. 
> 
> Andrus
> 
> On Dec 14, 2012, at 7:37 AM, John Huss <johnthuss@gmail.com> wrote:
> 
>> The problem with this is that Select<T> is an empty interface, and because
>> ObjectContext* and SelectQuery are in different packages the Select<T>
>> interface must be public.  So there is nothing preventing someone from
>> making any class implement Select<T> and then passing it to
>> objectContext.select().  If these were in the same package, then Select
>> could have package access and be expected to be internal to cayenne; but
>> that is not the case.
>> 
>> Given that, I am in favor of sticking with the original proposal to
>> override performQuery for SelectQuery<T> only and save the more generic
>> solution for a release with more dramatic changes that would involve
>> actually fleshing out a real interface for Select.  The override does not
>> minimize or conflict with any other future improvements in this direction
>> so there isn't really anything to lose.
>> 
>> John
>> 
>> 
>> On Tue, Dec 11, 2012 at 10:58 AM, Andrus Adamchik <andrus@objectstyle.org>wrote:
>> 
>>> Maybe to resolve it we call the new method something else? E.g.:
>>> 
>>> List<T> select(Select <T> query)
>>> 
>>> On Dec 10, 2012, at 6:54 PM, John Huss <johnthuss@gmail.com> wrote:
>>> 
>>>> The interface type is not sufficient to disambiguate the overloading.  If
>>>> you overload it this way the compiler complains "the method
>>> performQuery()
>>>> is ambiguous" since SelectQuery is both a Query and a Select<T>.  It
can
>>>> only resolve the issue if you query is declared this way:
>>>> 
>>>>   Select<T> query = new SelectQuery...
>>>> 
>>>> which prevents you from using any of the API in SelectQuery.  I suppose
>>> you
>>>> could provide builder (with the fluent API we've discussed) that returned
>>>> the final result as Select<T>, but again then at that point you would
>>> have
>>>> an opaque object that you couldn't easily modify.  That's generally how
>>>> builders work though, so it might be fine; but existing code would have
>>> to
>>>> be rewritten to use it.
>>>> 
>>>> If we stick with the overloading using SelectQuery<T> we could still
add
>>>> other overloads for specific types as well, it just gets repetitious.
>>>> 
>>>> 
>>>> On Mon, Dec 10, 2012 at 4:09 AM, Andrus Adamchik <andrus@objectstyle.org
>>>> wrote:
>>>> 
>>>>> A great approach to break our deadlock of on this feature! But maybe
we
>>>>> leave a bit more room for future extension by defining an interface for
>>>>> generics selecting query:
>>>>> 
>>>>> interface Select<T>
>>>>> 
>>>>> SelectQuery<T> extends QualifiedQuery implements Select<T>
>>>>> 
>>>>> List<T> performQuery(Select <T> query)
>>>>> 
>>>>> Then we can reuse the same ObjectContext method for other queries we
>>> might
>>>>> invent.
>>>>> 
>>>>> Andrus
>>>>> 
>>>>> 
>>>>> On Dec 10, 2012, at 9:05 AM, John Huss (JIRA) <jira@apache.org>
wrote:
>>>>>>  [
>>>>> 
>>> https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>> ]
>>>>>> 
>>>>>> John Huss updated CAY-1294:
>>>>>> ---------------------------
>>>>>> 
>>>>>> Attachment:
>>>>> 0002-Minimize-compiler-warnings-about-missing-type-parame.patch
>>>>>> 
>>>>> 0001-Add-type-parameter-to-SelectQuery-to-indicate-query-.patch
>>>>>> 
>>>>>> Here is an implementation of a generified SelectQuery.  It doesn't
>>>>> require any new API - there is simply an overloaded version of
>>>>> ObjectContext.performQuery for SelectQuery<T> that returns List<T>.
>>>>>> 
>>>>>> <T> List<T> performQuery(SelectQuery<T> query);
>>>>>> 
>>>>>> The <T> is unbounded because it has to support DataRows in
addition to
>>>>> Persistent objects.  The end result of course is that you can avoid
>>> having
>>>>> to cast the query result from List to List<Artist> and you avoid
the
>>>>> compiler warning.  This seems like a simple win - any objections?
>>>>>> 
>>>>>> I also added a static method to create an instance because if you
use
>>>>> this you can avoid repeating the class name twice, as in new
>>>>> SelectQuery<Artist>(Artist.class, null), which feels very tedious.
 So
>>> if
>>>>> you prefer you can call SelectQuery.from(Artist.class, null) instead
>>> and it
>>>>> will infer List<Artist> as the query result type.
>>>>>> 
>>>>>> public static <T> SelectQuery<T> from(Class<T>
rootClass, Expression
>>>>> qualifier);
>>>>>> 
>>>>>>> Generify query
>>>>>>> --------------
>>>>>>> 
>>>>>>>             Key: CAY-1294
>>>>>>>             URL: https://issues.apache.org/jira/browse/CAY-1294
>>>>>>>         Project: Cayenne
>>>>>>>      Issue Type: Improvement
>>>>>>>      Components: Core Library
>>>>>>>        Reporter: Ari Maniatis
>>>>>>>        Assignee: Andrus Adamchik
>>>>>>>         Fix For: Undefined future
>>>>>>> 
>>>>>>>     Attachments:
>>>>> 0001-Add-type-parameter-to-SelectQuery-to-indicate-query-.patch,
>>>>> 0002-Minimize-compiler-warnings-about-missing-type-parame.patch
>>>>>>> 
>>>>>>> 
>>>>>>> Although most of the generics work has been completed for 3.0,
'query'
>>>>> is still largely untouched. From a mailing list post by Andrus, here
are
>>>>> possible query result types:
>>>>>>> ? extends Persistent
>>>>>>> ? extends Object (unfinished POJO implementation)
>>>>>>> CayenneDataObject (as in "generic persistence" [1])
>>>>>>> DataRow
>>>>>>> scalar
>>>>>>> Object[] (a mix of scalars and any of the above)
>>>>>>> Certainly having a typed result list would be very useful in
the most
>>>>> common case of <? extends Persistent>.
>>>>>> 
>>>>>> --
>>>>>> This message is automatically generated by JIRA.
>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>> administrators
>>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
> 
> 


Mime
View raw message