Hi Joseph,
Thanks for posting this question here. And thanks, Samir, for sharing your
thoughts. I'm very curious about other people's opinion on this subject.
Obviously, I have thought about this before as MyBatis has seen a certain
level of popularity in the past. For the record, here's the reply I had
given to Joseph as to why jOOQ doesn't want to go in MyBatis' direction:
At some point, we had considered implementing a small templating language
> in jOOQ in order to compete with MyBatis, and to provide a migration path.
> And in fact, we do have one: The plain SQL templating language as
> documented here (query elements can include each other via {0} … {1}
> placeholders:
> http://www.jooq.org/doc/latest/manual/sql-building/plain-sql
>
> But in the end, the MyBatis “philosophy” is completely orthogonal to
> everything we like: to type safety. You can achieve the same goals in a
> completely typesafe way:
>
> 1. By using database views and possibly also table-valued
> functions. The DBA can compile them and tune them directly, without Java
> developer awareness. You can layer views in two levels, e.g. have
> DEV_VIEW_XYZ, which selects everything from DBA_VIEW_XYZ, in order for
> developers to communicate row type expectations to the DBA. Note that this
> architecture is also excellent if you wish to add an additional security
> layer in your views (e.g. Oracle’s WITH CHECK OPTION).
> 2. By using Java 8 functional programming methods, and potentially
> by using third party libraries like model mapper.
>
> With this approach, you reach the same goal in a SQL/jOOQ way, i.e. by
> leveraging your database’s and Java compiler’s type checking capabilities.
> After all, why use jOOQ when you hide all SQL in text files and XML mapping
> algorithm specifications?
The important thing here is: jOOQ is very much about giving DBA / SQL
developers much control over database design. Even if jOOQ means you're
embedding a lot of SQL using a not-exactly-SQL language (jOOQ) in Java,
this doesn't mean that you cannot move parts outside of Java, e.g. in
external files ("plain SQL"), or better: In database views and stored
procedures.
I just don't think that aside from jOOQ, there's a real need for a
templating language. Because if you do have that need, you can still write
code in PL/SQL (or any other procedural SQL language).
--
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/d/optout.
