Hi Lukas,
> Nice. So the API generation configuration dimensions are: > - Dialect support > - Strictness > - API naming strategies > In fact, I wonder if there should not be an additional item: - Target language of choice If you specify "Java" as your language criteria, keywords and operators may be different than if you say "Scala". This also has something do to with language-specific reserved keywords and syntax sugar. > 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/ > Yes, this probably makes sense though I fear we developers are going to argue what is considered "simple" :) > I'm even dreaming of putting RRDiagram SVGs into the generated Javadoc :-) > Ah, if only our free time were infinite and conversion of DSL to BNF be an easy problem! ;) > 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. > Yes, this might be the only way to find the right solution. I currently don't know whether the model API should be somewhat exposed or if it can only be an internal thing, so that the exposed facade is the only API. I tend to think that the model should be hidden as an internal API, after all, all jOOQ objects are interfaces (Row, Field, etc.) which could call that internal immutable API in their implementation. > So, you think that an API union of strict APIs is useful? > I really meant union :) jOOQ defaults to a union of all possible dialects, but in my case I just want to restrict to the 2 (or more) database dialects that we use. That way, we use the common subset, except when we have an issue and make a switch/case on the dialect to perform dialect-specific operations. Having this union means I would remove the noise of dialects that we definitely not care about. According to your use-case, would API union / intersection include data > types? > It should :) But this multi-dialect handling in jOOQ is not clear for me, as I mentioned in an earlier post. You could also consider that multi-dialect is a marginal case that you don't want to support, to reduce the issue to one or all dialects. > How about stored procedures? There will be caveats, of course :-) > I know, but in case of doubt, well, ignore the criteria. Speaking about the model, when a user decides to not use the default facade, they would probably have to regenerate their model using their criterias. Generated model and DSL have to be in sync. 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.
