cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <>
Subject Re: Chainable SelectQuery
Date Tue, 07 Oct 2014 22:44:27 GMT
On 8/10/2014 1:31am, John Huss wrote:

> I'm not a fan of methods that return "this" because it is impossible to
> tell (without looking at javadoc) whether a new instance or the same
> instance is returned.

This pattern was named "fluent" by Martin Fowler.

> That said, if returning this is the direction we're going, then really all
> the currently void methods in SelectQuery should do the same thing - like
> addOrdering for example.

Correct, but we also need to gracefully deprecate the old methods and make new fluent ones.

> Personally, I prefer to keep the select at the front to make it read like
> SQL.  I'd prefer something like this:

What if you don't want to pass a limit? Remember that the limit runs on the db as part of
the query, not on the resulting collection of objects.

> I'd take a bit to examine other ORMs to see what their APIs look like for
> this.

My personal experience is with Rails. And their query syntax is very much fluent style.

Client.where("orders_count > 10").order(:name).limit(10).reverse_order

Of course Ruby has advantages as a language to create cleaner APIs over Java. Some things
you just cannot easily achieve in Java.

I love this syntax for creating a list view of datarows:

Client.pluck(:id, :name)
# SELECT, FROM clients
# => [[1, 'David'], [2, 'Jeremy'], [3, 'Jose']]

Prefetching is done like this:

Client.includes("orders").where(first_name: 'Ryan', orders: { status: 'received' })

And aggregate functions like this:

Client.where(first_name: 'Bob').count


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

View raw message