Hi Christopher, 2013/6/25 Christopher Deckers <[email protected]> > 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. >
That would be nice. In fact, it would be very useful, if jOOQ Scala APIs could explicitly overload operators, instead of relying on implicit defs in a separate Java to Scala conversion object, as it is implemented now. Of course, it would be good to think about other Scala language elements, which could be leveraged that way, e.g. the use of Field[Option[Int]] for what is a nullable Field[Integer] in Java, e.g. the use of Scala collections instead of Java ones, etc. But I think that will be food for thought for jOOQ 5.0. :-) > 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" :) > You're a wise man :-) How about https://github.com/jOOQ/jOOQ/issues/2557 In other words, "simple" simulation must not repeat any expressions from the original clause / function. This would make my previous "simple" example a "transformative" one. It would be a useful distiction, as users will have to be more careful when using "transformative" simulations, rather than "simple" ones. Or, as Roger Thomas put it, if RANDOM() cannot be passed to a function simulation, it is no longer "simple". See this other discussion about SQL function simulation for details: https://groups.google.com/forum/#!topic/jooq-user/N5VZtLvnNH0 > 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! ;) > Yeah. In that order! :-) > 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. > That's the question. Are Row, Field DSL or model API? Or both, as they are now? This has to be explored. I'm not 100% sure if a clean separation is: - possible - desireable We'll see... > 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. > I see, yes of course, this is a use-case. So when selecting dialects, one can specify whether union or intersection should be applied. Maybe, the strictness level can even be specified on a dialect-basis, e.g. Oracle: Strict INTERSECT H2: Transformative ... if that makes sense? > 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. > It's not so marginal. Many users will use H2 or HSQLDB as test databases, even if I wouldn't recommend it, personally. > 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. > True. This is easy to check with the compiler. 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.
