Hi Christopher 2013/4/1 Christopher Deckers <[email protected]>: > Hi Lukas, > > I wanted to understand the result of Executor.selectXX(XX). I found this > hierarchy: > QueryPart > Query > ResultQuery<R extends Record> > Select<R extends Record> > SelectFinalStep<R extends Record> > SelectForUpdateStep<R extends Record> > SelectLimitStep<R extends Record> > SelectOrderByStep<R extends Record> > SelectHavingStep<R extends Record> > SelectGroupByStep<R extends Record> > SelectConnectByStep<R extends Record> > SelectWhereStep<R extends Record> > SelectFromStep<R extends Record> > SelectSelectStep<R extends Record> > > I may be mistaken, so correct me if I am wrong, but I have the feeling that > intermediate types between SelectSelectStep and ResultQuery are > capabilities. If this is so, then the hierarchy should be: > QueryPart > Query > ResultQuery<R extends Record> > SelectSelectStep<R extends Record>
Yes, that would be nice. > with: > SelectSelectStep extends ISelect, IFinal, IForUpdate, ILimit, IOrderBy, > IHaving, IGroupBy, IConnectBy, IWhere, IFrom > > These interfaces would not extend any particular hierarchy. The "I"Naming is > so you get the idea of what I am trying to say. This implementation wouldn't be my preferred one, though. It doesn't reduce API complexity. It just moves it elsewhere. As you've noted further down, the SelectSelectStep might even become obsolete, once its "capabilities" are externalised to these "I-Interfaces". > In fact, I don't think these intermediate "steps" are meaningful to users, > and they are not exposed in the Executor API, so "SelectSelectStep" should > just be renamed to "Select" (or ISelect, QuerySelect, etc.) and the internal > one have a different name. This would result in a flat hierarchy where types > have capabilities, easy to navigate and comprehend. A signature that reads > "QuerySelect select()" looks cleaner than "SelectSelectStep select()" where > to know what SelectSelectStep means we have to go through a 14-level > hierarchy of Javadoc with no apparent logic as to why one inherits another. > > Eventually, SelectImpl would implement Select, instead of SelectSelectStep. > Going further, flatening all of these would result in the type hierarchy of > QueryPart to be an effective way to understand jOOQ types (for now, hitting > F4 on QueryPart in Eclipse results in a mind boggling structure). I agree that 14 levels of hierarchy are not very user-friendly. While auto-completion in an IDE still works nicely, non-IDE users, or users using other IDE features, such as hierarchy views may be put off by so much inheritance. To be sure that we're discussing on a common grounds, I assume that the fluent API building technique, which jOOQ is based on, is known: http://blog.jooq.org/2012/01/05/the-java-fluent-api-designer-crash-course Now, if I were to implement this hierarchy, as you proposed... > QueryPart > Query > ResultQuery<R extends Record> > SelectSelectStep<R extends Record> ...I would have to push down all methods from SelectFromStep, SelectWhereStep, SelectConnectByStep, etc. to SelectSelectStep (or whatever this would be named). This would be necessary to offer all "optional" SQL keywords through the DSL API. The resulting API would be completely equivalent from an API consumer perspective, except that inheritance has almost been removed. Manually maintaining such an API is almost impossible, though. Think of all the method declaration duplication, and the resulting duplicate Javadocs. I have a task on the roadmap, that takes a BNF notation with some documentation annotation as input, and outputs the fluent API: https://github.com/jOOQ/jOOQ/issues/721. However, I think that such an API rework will have to be postponed to jOOQ 4.0 Cheers Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
