Hi Christopher, 2013/6/25 Lukas Eder <[email protected]>
> 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. :-) > Just a short note, why Scala would need to be looked at in a much broader context. Check out how sqltyped leverages Scala 2.10 Macros to produce typesafety from SQL strings (strings!) https://github.com/jonifreeman/sqltyped This is quite impressive, although not very usable in its current form. E.g. SQL strings need to be constants (I think) for the Macro processor to be able to construct a compile-time AST. This makes dynamic SQL impossible. But for inline SQL, it could be quite powerful. What I'm trying to say is, it may be worth evaluating to write scooq, instead of adding 1-2 utilities to jOOQ. Or since Scala is mainly functional, not OO, a "better" name might be scfq ;-) > > >> 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.
