Hi Lukas, While not very active, I did keep an eye on this discussion, and I too found your answer to be very valuable. I am glad to see it making it somewhere in the manual.
Languages have reserved keywords, so mapping a language to another is likely to clash on some reserved keywords. The amount of clash depends on the languages that we consider and tricks we can apply. One consideration is about the target languages: should we have the same considerations for jOOQ used in Java and jOOQ used in say Scala? I will use "Scala" as a generic way of saying "other languages" throughout the discussion. Of course I understand that jOOQ's primary target is Java, but I am curious. *1. By introducing artificial keywords. Examples* > > SQL: UPDATE t SET a = 1, b = 2 > jOOQ: update(t).set(a, 1).set(b, 2) > Note that this example also shows missing operator overloading > capabilities, where "=" is replaced by "," > Would jOOQ on Scala be able to more closely match such construct if one wanted to? > SQL: ORDER BY > jOOQ: orderBy() > Would jOOQ on Scala be able to more closely match such construct? I guess that would mean having ORDER(BY(xxx)) and then BY could be problematic if used in other places. *6. By using descriptive methods, or a comma* > > Most SQL operators have to be mapped to descriptive method names in Java: > > SQL: = > jOOQ: equal(), eq() > What is the rule with verbs? Should it be 3rd person, like "equals()" (if there were no collisions with Java's equals)? SQL: <> > jOOQ: notEqual(), ne() > Would jOOQ on Scala be able to more closely match such construct? > > *7. That cannot be worked around* > > This is what has been keeping me from implementing CTE so far. > > SQL: WITH a(x, y) AS (SELECT 1, 2) SELECT a.x, a.y FROM a > What is the problem with the above expression? > *Discussion* > > a) by using synonyms > This is the worst suggestion in my view. > b) by appending "disambiguators" such as case_ or case$ or case > I don't mind hard rules, like "any keyword that may clash with Java keyword is going to be suffixed with '_'". I prefer suffix, because code completion would work when I start typing "case". > c) by introducing artificial spelling, such as casë, casǝ, casɇ ;-) > OK, this *IS* the worst suggestion :) You forgot \uFF43\uFF41\uFF53\uFF45: ｃａｓｅ > d) by changing the API to be all-uppercase: SELECT(), CASE(), ORDER_BY() > My initial reaction was "ouch, this is ugly Java", but I do write SQL all caps, so having the DSL part be all caps to map SQL is really not that bad. > e) by changing the API to be camel-case with an upper-case initial letter: > Select(), Case(), OrderBy() > This is odd, because it is neither the Java convention nor SQL. d) and e) are massive changes. > Apart from being an incompatible API, what is the complexity? User manual mainly? > Any other ideas? > Apart from silly ideas like "cASE", not really :) 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.
