cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikita Timofeev <ntimof...@objectstyle.com>
Subject Re: API for aggregate and non aggregate SQL functions
Date Tue, 10 Jan 2017 07:14:20 GMT
On Tue, Jan 10, 2017 at 5:45 AM, Aristedes Maniatis <ari@maniatis.org> wrote:
> On 9/1/17 8:45pm, Nikita Timofeev wrote:
>> But your feedback is pushing me towards the solution that I didn't
>> want to use initially:
>> to introduce some abstract FluentSelect with descendants like
>> ObjectSelect and ColumnSelect.
>> Where ColumnSelect can be used directly or can be created within
>> column() or columns() method call in ObjectSelect (as you suggested in
>> the first place).
>>
>> Additional benefit of this new query that it can provide a nice
>> shortcut for the COUNT(*) query:
>>
>> long count = ColumnSelect.query(Artist.class, Property.COUNT)
>>         .where(Artist.ARTIST_NAME.like("artist%"))
>>         .selectOne(context);
>
>> And here is example for several properties:
>>
>> Object[] nameAndDate = ColumnSelect.query(Artist.class,
>> Artist.ARTIST_NAME, Artist.DATE_OF_BIRTH)
>>         .orderBy(Artist.ARTIST_NAME.asc())
>>         .selectFirst(context);
>
>
> I'm not convinced adding the columns to the constructor is any clearer than explicit
columns() calls.
>
>
>> or
>>
>> Object[] nameAndDate = ColumnSelect.query(Artist.class)
>>         .columns(Artist.ARTIST_NAME)
>>         .columns(Artist.DATE_OF_BIRTH)
>>         .orderBy(Artist.ARTIST_NAME.asc())
>>         .selectFirst(context);
>>
>> Do you think that this is a more clear way of doing columns queries?
>> Or it is excessive for the purpose of avoiding limitation of multiple
>> column() method calls?
>
>
> What are the issues we are trying to solve here?
>
> 1. Mixing columns() and column() is broken.
> 2. Simpler syntax for count() and max() frequently used methods
>
>
> I can't easily see how to solve (1) except by always returning List<Object[]> even
if Object[] only contains a single element (if there is just one column). Then we only have
column() which can take a collection of properties or vargs list of properties.
>

I'm sorry I wasn't clear enough with this idea. It's really close to
have only columns() method with varargs or collection that will always
return Object[], but with option to have single column in constructor
to still allow shortcuts.
So as long as there is no public column() method in ColumnSelect you
can't be confused with
ColumnSelect.query(Artist.class).columns(..).column(..) but still can
go with ColumnSelect.query(Artist.class, Artist.ARTIST_NAME).
And this can be nicely used for count() and other aggregates too.

-- 
Best regards,
Nikita Timofeev

Mime
View raw message