cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: API for aggregate and non aggregate SQL functions
Date Tue, 10 Jan 2017 02:45:28 GMT
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.

For (2), your idea of Property.COUNT as a special constructor of this type of property then
starts to be what you didn't want: Property class which knows about SQL expressions. But do
we care about this purity over a clean and simple API for users?


Ari


-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Mime
View raw message