Hi Christopher, Thanks for a wonderful compilation of jOOQ's mid-term mission! A couple of comments, inline:
2013/6/23 Christopher Deckers <[email protected]> > Hi Lukas, > > There starts to be several discussions that could be brought together, > revolving around the actual construction of the jOOQ DSL, its formalism, > supported dialects and versions, etc. > > > Created a new issue for jOOQ 4.0, to keep in the back of our heads: >> https://github.com/jOOQ/jOOQ/issues/2548 >> >> If the two APIs can be maintained in parallel, the change might also be >> introduced in a minor release in 3.x >> > > "For backwards-compatibility reasons, it would be important to maintain > the two APIs in parallel, potentially using a code generator to generate > one API from the other" > > > With Christopher Decker's recent helping in creating a >>> railroad-diagram tool [1] and Peter Verhas's inspiration, mapping a finite >>> state-machine to a fluent API (and / or a BNF), the language-aspects of >>> jOOQ will hopefully be heavily improved in the near future [3]. >>> >> > > So, what would be the ideal solution of creating jOOQ to have all the > features we dream of? > > Suppose a user wants one of (these are just some of the possible examples): > - strict API for a particular dialect and version of one RDBMS. > - strict+simulated for a common subset of dialects. > - all strict+simulated for all dialects. > - naming strategy as all caps. > - naming strategy as camelCase. > - documentation with BNF syntax and railroad diagrams for their selected > subset. > Nice. So the API generation configuration dimensions are: - Dialect support - Strictness - API naming strategies Note, I'm thinking about distinguishing "strictness" between - No simulation (strict) - "simple" simulation: syntactic equivalence, such as NVL(a, b) = CASE WHEN a IS NOT NULL THEN a ELSE b END - "transformative" simulation: transforming SQL to form very different SQL, e.g. LIMIT / OFFSET in Oracle, SQLServer 2008, LPAD() in SQLite (see other thread), or row value expressions and IN predicates: http://blog.jooq.org/2013/05/03/sql-query-transformation-fun-predicates-with-row-value-expressions/ It would be interesting to have the standard jOOQ being one set of these > possible choices but the user be able to generate/download his flavor that > restricts/adjusts jOOQ API. > Yes. The standard jOOQ would certainly include: - "transformative" simulation (no "strictness") - All SQL dialects - the camelCase() API Its goal is to get new users started as quickly as possible. Maybe, there will also be a parallel distribution with the UPPER_CASE() API for all dialects. The goal is that only advanced users will actually have to / want to make use of custom API generation. Then, it means the DSL generator is the central piece. The DSL generator > generates interfaces and methods (with Javadoc) that match the desired > criteria, as well as a BNF notation, from which syntax can be studied > eventually in the form of railroad diagrams. > I'm even dreaming of putting RRDiagram SVGs into the generated Javadoc :-) > The generator would somehow generate the implementation of these > interfaces that call core classes that never change. The whole jOOQ > internals never change, only the facade that is exposed to the user. A > different set of criteria simply means a different facade. Code completion > would be great and to the point! > Good point. So this creates the bridge to the clean DSL vs. model API separation, where the model API is mutable for dynamic SQL construction, whereas the DSL API can easily become immutable, as all the tedious work of making the DSL implementation immutable could be generated. The model API would be the only one manually annotated with: - @Support: documenting what SQLDialect supports a clause / method in strict / simple / transformative mode - @State / @Transition: documenting the language aspects (this may change as we gather experience) All of this will certainly have to be prototyped, as it is currently not clear how clean the separation of DSL and model API can be made. For instance, it is quite useful to have these methods on the same type: Row.IS_NULL() // DSL Row.fields() // Model Field.IS_NULL() // DSL Field.getType() // Model A clean alternative would of course be: Row.IS_NULL() // DSL Row.model().fields() // Model Field.IS_NULL() // DSL Field.model().getType() // Model Or some method other than model() to keep an open door for Oracle's MODEL clause. For example, my very own set of criteria would be: > - all caps. > - union of strict APIs for SQLServer 2008+ and Oracle 10. > > That way, the API would not simutate anything (strict SQL) and I would be > able to call SQLServer or Oracle specific functions conditionally when I > need. Of course, I would have to be careful not to call Oracle-specific > stuff when on SQLServer, but I would likely generate the strict API of each > just to keep the corresponding documentations and railroad diagrams at hand. > So, you think that an API union of strict APIs is useful? Or did you mean an API intersection (removing features that aren't available in *both* databases)? According to your use-case, would API union / intersection include data types? How about stored procedures? There will be caveats, of course :-) 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.
