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.
