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. http://martinfowler.com/bliki/FluentInterface.html > 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: > > context.select(SelectQuery.query(Artist.class).where(NAME.eq("Picasso")).orderBy(NAME.asc()).limit(1); 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 http://guides.rubyonrails.org/active_record_querying.html 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 clients.id, clients.name 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 Ari -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
