Absolutely. I was planning a model-based SQL building as the next step for
SQLSelect. The current version (that only took me maybe an hour to write)
streamlines casting the result to something that you need, binding parameters,
etc. I haven't looked at the SQL "payload" part of it yet. My note below about
"other methods for building SQL chunks based on Cayenne mapping, such as
"allColumns()" is essentially about doing something like you suggest.
In general designing this fluent API requires a bit different mindset compared
to designing "canonical" API that we have. Will need to better wrap my head
around it.
A.
On May 26, 2013, at 3:19 PM, Michael Gentry <mgen...@masslight.net> wrote:
> Hi Andrus,
>
> I may be missing something, but it looks like you'd have to do something
> such as:
>
> SQLSelect.query(Artist.class, "SELECT * FROM ARTIST WHERE ...");
>
> In most cases, you are always going to select "*" I think and artist is
> duplicated. Why not something more along the lines of:
>
> SQLSelect.on(Artist.class).where("...");
>
> Thanks,
>
> mrg
>
>
>
> On Fri, May 24, 2013 at 11:45 AM, Andrus Adamchik
> <and...@objectstyle.org>wrote:
>
>> https://issues.apache.org/jira/browse/CAY-1828
>>
>> http://svn.apache.org/repos/asf/cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/query/SQLSelect.java
>>
>> So SQLTemplate annoyed me enough to wrap it as a quick experiment with
>> fluent APIs. I guess this is the direction where the rest of the queries
>> should be going. Aside from chaining query configuration parameters, there
>> are "select" and "selectOne" methods that allow to take the chain to the
>> logical conclusion - the resulting objects.
>>
>> I can think of other methods for building SQL chunks based on Cayenne
>> mapping, such as "allColumns()", etc.
>>
>> What do you think? Also method naming criticism is accepted. E.g. I am not
>> sure that changing "setPageSize()" to "pageSize()" was such a great idea.
>>
>> Andrus
>>
>>
>>
