Discussion:
[jira] [Updated] (CAY-1294) Generify query
(too old to reply)
Andrus Adamchik
2012-12-10 10:09:27 UTC
Permalink
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
[ https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
---------------------------
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
? 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
John Huss
2012-12-10 15:54:40 UTC
Permalink
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.
Post by Andrus Adamchik
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
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
[
https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
---------------------------
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
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
? 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
http://www.atlassian.com/software/jira
Andrus Adamchik
2012-12-11 16:58:09 UTC
Permalink
Maybe to resolve it we call the new method something else? E.g.:

List<T> select(Select <T> query)
Post by John Huss
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
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.
Post by Andrus Adamchik
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
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
[
https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
---------------------------
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
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
? 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
http://www.atlassian.com/software/jira
John Huss
2012-12-11 18:11:31 UTC
Permalink
That's what I was thinking too this morning.
Post by Andrus Adamchik
List<T> select(Select <T> query)
Post by John Huss
The interface type is not sufficient to disambiguate the overloading. If
you overload it this way the compiler complains "the method
performQuery()
Post by John Huss
is ambiguous" since SelectQuery is both a Query and a Select<T>. It can
Select<T> query = new SelectQuery...
which prevents you from using any of the API in SelectQuery. I suppose
you
Post by John Huss
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
Post by John Huss
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
Post by John Huss
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.
Post by Andrus Adamchik
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
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
Post by John Huss
Post by Andrus Adamchik
invent.
Andrus
[
https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Post by John Huss
Post by Andrus Adamchik
---------------------------
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
Post by John Huss
Post by Andrus Adamchik
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
Post by John Huss
Post by Andrus Adamchik
you prefer you can call SelectQuery.from(Artist.class, null) instead
and it
Post by John Huss
Post by Andrus Adamchik
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
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
? 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
http://www.atlassian.com/software/jira
Aristedes Maniatis
2012-12-11 22:20:36 UTC
Permalink
Post by Andrus Adamchik
List<T> select(Select <T> query)
In this case would you narrow the scope of T to just Persistent objects, and cover the 99% use-case with this (I imagine that DataRows is a much less common requirement)?

I promise I'm not trying to feature creep this... the last time we did, development of the generified API stalled for two years.

Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
John Huss
2012-12-11 22:34:04 UTC
Permalink
You would have to limit the bound on SelectQuery as well, which isn't
really ok. What advantage does the lower bound give you anyway?

The long term solution would be to provide new separate Select<T>
implementations (not SelectQuery) for the different result types.
Post by Aristedes Maniatis
Post by Andrus Adamchik
List<T> select(Select <T> query)
In this case would you narrow the scope of T to just Persistent objects,
and cover the 99% use-case with this (I imagine that DataRows is a much
less common requirement)?
I promise I'm not trying to feature creep this... the last time we did,
development of the generified API stalled for two years.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
John Huss
2012-12-14 04:37:21 UTC
Permalink
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
Post by Andrus Adamchik
List<T> select(Select <T> query)
Post by John Huss
The interface type is not sufficient to disambiguate the overloading. If
you overload it this way the compiler complains "the method
performQuery()
Post by John Huss
is ambiguous" since SelectQuery is both a Query and a Select<T>. It can
Select<T> query = new SelectQuery...
which prevents you from using any of the API in SelectQuery. I suppose
you
Post by John Huss
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
Post by John Huss
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
Post by John Huss
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.
Post by Andrus Adamchik
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
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
Post by John Huss
Post by Andrus Adamchik
invent.
Andrus
[
https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Post by John Huss
Post by Andrus Adamchik
---------------------------
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
Post by John Huss
Post by Andrus Adamchik
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
Post by John Huss
Post by Andrus Adamchik
you prefer you can call SelectQuery.from(Artist.class, null) instead
and it
Post by John Huss
Post by Andrus Adamchik
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
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
? 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
http://www.atlassian.com/software/jira
Andrus Adamchik
2012-12-14 07:56:16 UTC
Permalink
Post by John Huss
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
Post by John Huss
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
Post by Andrus Adamchik
List<T> select(Select <T> query)
Post by John Huss
The interface type is not sufficient to disambiguate the overloading. If
you overload it this way the compiler complains "the method
performQuery()
Post by John Huss
is ambiguous" since SelectQuery is both a Query and a Select<T>. It can
Select<T> query = new SelectQuery...
which prevents you from using any of the API in SelectQuery. I suppose
you
Post by John Huss
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
Post by John Huss
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
Post by John Huss
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.
Post by Andrus Adamchik
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
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
Post by John Huss
Post by Andrus Adamchik
invent.
Andrus
[
https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Post by John Huss
Post by Andrus Adamchik
---------------------------
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
Post by John Huss
Post by Andrus Adamchik
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
Post by John Huss
Post by Andrus Adamchik
you prefer you can call SelectQuery.from(Artist.class, null) instead
and it
Post by John Huss
Post by Andrus Adamchik
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
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
? 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
http://www.atlassian.com/software/jira
Andrus Adamchik
2012-12-18 08:29:04 UTC
Permalink
Started using the new API. Very cool! One note - maybe in addition (instead of?) to Cayenne.objectForQuery we need Cayenne.objectForSelect(..) ?
Post by Andrus Adamchik
Post by John Huss
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
Post by John Huss
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
Post by Andrus Adamchik
List<T> select(Select <T> query)
Post by John Huss
The interface type is not sufficient to disambiguate the overloading. If
you overload it this way the compiler complains "the method
performQuery()
Post by John Huss
is ambiguous" since SelectQuery is both a Query and a Select<T>. It can
Select<T> query = new SelectQuery...
which prevents you from using any of the API in SelectQuery. I suppose
you
Post by John Huss
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
Post by John Huss
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
Post by John Huss
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.
Post by Andrus Adamchik
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
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
Post by John Huss
Post by Andrus Adamchik
invent.
Andrus
[
https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Post by John Huss
Post by Andrus Adamchik
---------------------------
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
Post by John Huss
Post by Andrus Adamchik
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
Post by John Huss
Post by Andrus Adamchik
you prefer you can call SelectQuery.from(Artist.class, null) instead
and it
Post by John Huss
Post by Andrus Adamchik
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
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
? 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
http://www.atlassian.com/software/jira
John Huss
2012-12-18 23:00:19 UTC
Permalink
Sounds like a good idea.
Post by Andrus Adamchik
Started using the new API. Very cool! One note - maybe in addition
(instead of?) to Cayenne.objectForQuery we need Cayenne.objectForSelect(..)
?
Post by Andrus Adamchik
Post by John Huss
The problem with this is that Select<T> is an empty interface, and
because
Post by Andrus Adamchik
Post by John Huss
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.
Post by Andrus Adamchik
Andrus
Post by John Huss
The problem with this is that Select<T> is an empty interface, and
because
Post by Andrus Adamchik
Post by John Huss
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
Post by Andrus Adamchik
Post by John Huss
minimize or conflict with any other future improvements in this
direction
Post by Andrus Adamchik
Post by John Huss
so there isn't really anything to lose.
John
On Tue, Dec 11, 2012 at 10:58 AM, Andrus Adamchik <
Post by Andrus Adamchik
List<T> select(Select <T> query)
Post by John Huss
The interface type is not sufficient to disambiguate the overloading.
If
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
you overload it this way the compiler complains "the method
performQuery()
Post by John Huss
is ambiguous" since SelectQuery is both a Query and a Select<T>. It
can
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Select<T> query = new SelectQuery...
which prevents you from using any of the API in SelectQuery. I
suppose
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
you
Post by John Huss
could provide builder (with the fluent API we've discussed) that
returned
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
the final result as Select<T>, but again then at that point you would
have
Post by John Huss
an opaque object that you couldn't easily modify. That's generally
how
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
builders work though, so it might be fine; but existing code would
have
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
to
Post by John Huss
be rewritten to use it.
If we stick with the overloading using SelectQuery<T> we could still
add
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
other overloads for specific types as well, it just gets repetitious.
On Mon, Dec 10, 2012 at 4:09 AM, Andrus Adamchik <
Post by Andrus Adamchik
A great approach to break our deadlock of on this feature! But maybe
we
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
leave a bit more room for future extension by defining an interface
for
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
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
Post by John Huss
Post by Andrus Adamchik
invent.
Andrus
[
https://issues.apache.org/jira/browse/CAY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
]
Post by John Huss
Post by Andrus Adamchik
---------------------------
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
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Persistent objects. The end result of course is that you can avoid
having
Post by John Huss
Post by Andrus Adamchik
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
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
this you can avoid repeating the class name twice, as in new
SelectQuery<Artist>(Artist.class, null), which feels very tedious.
So
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
if
Post by John Huss
Post by Andrus Adamchik
you prefer you can call SelectQuery.from(Artist.class, null) instead
and it
Post by John Huss
Post by Andrus Adamchik
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
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'
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
is still largely untouched. From a mailing list post by Andrus, here
are
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
? 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
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
Post by John Huss
Post by Andrus Adamchik
common case of <? extends Persistent>.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
http://www.atlassian.com/software/jira
Loading...