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. 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. 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. 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! 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. Cheers, -Christopher -- 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.
