Hi Ariel,
2014-06-26 15:32 GMT+02:00 Ariel Tal <[email protected]>:
> Null handling is indeed not trivial, but I think this is more relevant for
> eq/ne than for gt/in - gt(null) should throw an NPE in my opinion,
>
What about gt(val(null))? Or gt(DSL.field("null"))? Or gt(DSL.field("?",
null))?
> and in(null) should probably translate to IN () ).
>
IN () is probably not a very good idea :-)
For the reference, here's the syntax specs from the SQL standard:
<in predicate> ::=
<row value constructor>
[ NOT ] IN <in predicate value>
<in predicate value> ::=
<table subquery>
| <left paren> <in value list> <right paren>
<in value list> ::=
<value expression> { <comma> <value expression> }...
Empty <in value list> are not possible... Besides, in(null, 1) is a valid
predicate, again...
Leaving it up to the user is a reasonable decision.
>
I think it's the only reasonable decision, given that even if translating
eq(null) / ne(null) seems to be a low-hanging fruit at first, it is
completely unexpected and inconsistent with pretty much all of the other
API.
> In my case the column is nullable and I ended up creating a wrapper
> eqOrIsNull and neOrNotNull to get the behavior I was expecting.
>
Hmm, yes, that could be useful. Essentially, you're generating A = x OR x
IS NULL for A.eq(x)?
Best,
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.
