On 16/1/17 8:41pm, Hugi Thordarson wrote: > One thing that I find a little bothersome (and at times confusing) when using > these APIs though is how return types change based on what you’re fetching, > especially how the type will change between List<Object> to List<Object[]> > based on if I’m fetching multiple columns or a single column (I see this was > discussed a little on the list the other day). As an API consumer I think it > would be much nicer if fetches consistently returned List<Object[]>.
The problem is that the result type depends on too many different things: * the execute function: select(), selectOne() * the initial constructor: dataRowQuery(), query() * something in the middle: columns(), column() * maybe some shortcut execute function (if we want to add such a thing) like: max(), sum() Would a different initial constructor make things clearer (as Nikita's idea)? columnQuery(<T>Artist.class) -> ColumnSelect<T> or is it simply enough to always return List<Object[]> and never List<Object>. That way, we never worry about mixing columns() and column(). When we want shortcuts for count() and sum(), then we could add another constructor like this: sum(Artist.class, <T>property) -> AggregateSelect<T> max(Artist.class, <T>property) -> AggregateSelect<T> min(Artist.class, <T>property) -> AggregateSelect<T> count(Artist.class, <T>property) -> ScalarSelect<Integer> Is that too much? I don't think we need more shortcuts than those. And these classes would not implement orderBy(), pageSize() or prefetch() Ari -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
