On Mon, Dec 1, 2014 at 11:23 PM, Lukas Eder <[email protected]> wrote:
> There is certainly room for improvement in that area. The two modes of
> operation are very similar in the way they're used throughout the API as
> both operations simply require String arguments, and String doesn't have
> have a semantics per se.
Correct. You could require the raw SQL statements to be wrapped in DSL.raw():
DSL.select().from(DSL.raw("plain SQL table"))
vs
DSL.drop("tableByName")
The advantage of doing this is that:
* Forgetting to do something (i.e. forgetting to call DSL.raw) does
not lead to potentially unsafe code.
* The code is more explicit. When you are reading the code, you know
what is going on.
* If DSL.raw is used consistently, it makes it easy to audit / setup a
commit hook / highlight things at code review time / etc.
> One way to disambiguate this would be to deprecate the tableByName and
> fieldByName methods (and all methods that accept strings with a "Name"
> semantics), and offer alternative API methods accepting the org.jooq.Name
> type:
>
> DSL.table(DSL.name("tableByName"));
> DSL.field(DSL.name("fieldByName"), Integer.class);
Would you keep the DSL.table(String), DSL.field(String) methods? If
yes, I think it's safer to do it the other way around for the reasons
I mentioned above.
> This would make using the jOOQ API a bit more verbose, but it might still be
> acceptable.
The API becomes a bit more verbose (an extra method call around a
bunch of (hopefully) static strings). However don't forget the API
becomes simpler (since you can deprecate/remove tableByName,
fieldByName, etc.). Overall it's a reduction in the cognitive work for
the library users.
Alok
--
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.
