For the record, checker framework support is now available in jOOQ 3.9, although you can also manually backport the module to work with earlier releases. More details here: https://blog.jooq.org/2016/05/09/jsr-308-and-the-checker-framework-add-even-more-typesafety-to-jooq-3-9/
Am Mittwoch, 10. Dezember 2014 11:21:08 UTC+1 schrieb Lukas Eder: > > > > 2014-12-09 19:06 GMT+01:00 Alok Menghrajani <[email protected]>: >> >> >> DSL.raw() does not need to actually return an escaped string. It could >> return an object, something like: >> >> class RawString { >> private String raw; >> >> public RawString(String raw) { >> this.raw = raw; >> } >> >> public String escapeForSchema() { >> ... >> } >> public String escapeForTable() { >> ... >> } >> etc. >> } >> >> RawString's escape methods would then get called by the API as needed. >> DSL.raw() could be seen as a promise to escape your string, once the >> context is known. >> > > While there can certainly be an object called something like RawString > with no specific AST semantics, users will inevitably want to combine the > type of object they had in mind with other operations. For example, they > will want to compare plain SQL fields with other values, such as today: > > DSL.field("some-complex-expression").eq(42) > > > From a usability perspective, it is crucial that the actual AST type be > strongly typed towards Schema, Table, Field, Sequence semantics. > > The semantics of escaping is already properly handled in jOOQ internally > and shouldn't be exposed publicly. It won't add much value to API > consumers, in my opinion. > > > That's a good point, although, you're inserting strings into the API. >> This >> > has an implicit feel of "ooh, am I doing this right?" I agree, though >> that >> > terms like "raw" would make users even more alert. >> >> I'm glad we agree on the same things :) > > > Yep :-) > > Albeit, we won't introduce "raw()" as a method name as all of the manual > and Javadoc refers to "raw" as "plain SQL". So the method will be called > "DSL.sql()". There are also plans of supporting a "sql()" method in all of > the DSL to inject local SQL strings for vendor-specific features or > comments. So the two method names will be aligned. > > >> To me, it's unclear in which case it's ok to use externally controlled >> strings and in which case it's not ok. I would love to get the opinion >> of all the other people on this list. >> > > I agree, any opinion is welcome. > > >> > No matter how we evolve this, it would be useful to annotated >> potentially >> > dangerous methods this way. We have already added the same SQL injection >> > warning in all Javadocs, but formal client-side validation might be even >> > better. We'll be doing some research and blog about JSR-308 pretty >> soon... >> >> http://bunkstrutts.files.wordpress.com/2011/11/corgi-bounci.gif > > > Well, that just about made my day ;-) > > 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/d/optout.
