On Tue, Jan 10, 2017 at 5:45 AM, Aristedes Maniatis <a...@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
