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 Fri, 14 Dec 2012 07:56:16 GMT
> 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