Hi Lukas,

Thank you for the explanation, and information!  I will have a look at the
custom bindings link that you provided.
I definitely don't want to turn off all of JOOQ's type conversion, but I am
aiming to find a way to force it to not convert in the case of NaN.

As we discussed, that is pretty much going against the nature of JOOQ, so
it may not be straightforward.
I'll let you know what I can come up with after reading the info you
provided.

Thanks!
-Charlie

On Mon, Apr 9, 2018 at 12:12 AM, Lukas Eder <lukas.e...@gmail.com> wrote:

> Hi Charlie,
>
> Thanks for explaining. I think I see now what you're trying to do,
> although, I'm not sure why you're doing it. In any case, here's the
> explanation of the current behaviour:
>
> jOOQ tries to implement as useful data type specific behaviour as
> possible, if the column data type <T> (as in DataType<T> or Field<T>) is
> known to jOOQ. If jOOQ knows that the expression is of type BIGINT
> (java.lang.Long), then jOOQ will try to automatically convert any input
> type to java.lang.Long. This includes all other java.lang.Number types
> (through Number.longValue()). As you can easily confirm in a jshell:
>
> jshell> ((Double) Double.NaN).longValue()
> $1 ==> 0
>
>
> Now, in the past, there have been discussions about whether jOOQ should
> rather throw / fail early on such occasions, rather than convert silently.
> Both approaches have their pros and cons. Currently, jOOQ converts
> silently, in the client, prior to sending the long value to the JDBC driver
> and then to the server.
>
> You want jOOQ not to use the java.lang.Long / long types, internally. This
> can be achieved on a per-bind value case through using data type bindings.
> You should probably find a way to turn all of your data types to
> DataType<Object> and implement the binding yourself. More details here:
> https://www.jooq.org/doc/latest/manual/code-generation/
> custom-data-type-bindings
>
> Of course, you'd lose all the type safety offered by jOOQ and I still
> don't see the point of why you're trying to do this, so I don't see the
> value of adding a Setting that turns off all of the useful auto-conversion
> that goes on in jOOQ, specifically because it would be rather difficult to
> maintain. I'm hypothesising that this need of yours derives from a problem
> entirely elsewhere, which you should definitely solve outside of jOOQ.
>
> Hope this helps,
> Lukas
>
> 2018-04-08 2:58 GMT+02:00 Charles Henry <che...@snaplogic.com>:
>
>> Hi Lukas,
>>
>> Thanks so much for responding to me!  For starters, I agree with you.  I
>> think what I am trying to do sort of goes against what JOOQ is trying to do.
>> Yes, sometimes I definitely ramble and think aloud as I go along :-)
>> Before I start a new message, I'll describe the issue in a minimal
>> fashion here:
>>
>> -Communicating with a Postgresql Dialect (but will be many other dialects)
>> -Postgresql doesn't support NaN input into a bigint/INT8 field.  JOOQ
>> knows this.
>> -JOOQ converts my NaN input into a 0, as should be expected.
>>
>> The question is:  Is there any programatic way in org.jooq.conf.Settings
>> (or anywhere else) that will force JOOQ to perform conversions, but NOT
>> convert NaN?  My mission is to
>> allow the NaN to be produced in the org.jooq.DslContext.InsertInto query
>> output, and let that value get to the database and error out.
>>
>> Thank you again for reading through my messages.  Again, I realize I am
>> trying to perform something that I believe JOOQ is not intended to do.  But
>> if there is a way, that would be awesome.
>> :-)
>> -Charlie
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Apr 7, 2018 at 2:33 AM, Lukas Eder <lukas.e...@gmail.com> wrote:
>>
>>> Hi Charles,
>>>
>>> Thank you very much for your messages. I see, you've been kinda having a
>>> conversation with yourself. :)
>>>
>>> In order to get to the same level, would you mind starting a new
>>> conversation again with the current state of your findings? Also, do not
>>> yet make any assumptions about a possible improvement that is required to
>>> jOOQ to fix your issue, prior to clearly communicating what your findings
>>> are, ideally via a MVCE:
>>> https://stackoverflow.com/help/mcve
>>>
>>> For example, I have no idea how to reproduce your issue, and I'm not
>>> even convinced that you really found a flaw or glitch in jOOQ, you might
>>> just be using the API wrong.
>>>
>>> Thanks,
>>> Lukas
>>>
>>> 2018-04-06 20:58 GMT+02:00 Charles Henry <che...@snaplogic.com>:
>>>
>>>> LOL, nope...I was wrong.  It was not preserved.
>>>>
>>>> On Friday, April 6, 2018 at 11:18:39 AM UTC-7, Charles Henry wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> I realize that one of the purposes of JOOQ is to ensure safe datatype
>>>>> conversions, and this question may be flying in the face of the purpose of
>>>>> JOOQ.
>>>>>
>>>>> I see that deep under the hood, say when communicating with Amazon
>>>>> Redshift, a BigInt or INT8 is treated as a Double, and if passed a "NaN"
>>>>> the value passed is treated as Double.NaN, which gets casted around and
>>>>> passed into Long.valueOf, which safely converts my NaN to a 0.
>>>>>
>>>>> I see no API hooks to disable this conversion.  Is there anything I
>>>>> can do to force JOOQ to keep the NaN regardless of datatype and SQL 
>>>>> dialect?
>>>>>
>>>>> Thanks folks,
>>>>> -Charlie
>>>>>
>>>> --
>>>> 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 jooq-user+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> 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 jooq-user+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Charles Henry
>> Sr. Software Engineer Snaps Team
>> che...@snaplogic.com
>>
>> *SnapLogic Inc | 1825 South Grant Street, 5th Floor | San Mateo CA 94402
>> | USA
>> <https://maps.google.com/?q=1825+South+Grant+Street,+5th+Floor+%7C+San+Mateo+CA+94402+%7C+USA&entry=gmail&source=g>*
>>
>> This message is confidential. It may also be privileged or otherwise
>> protected by work product immunity or other legal rules. If you have
>> received it by mistake, please let us know by e-mail reply and delete it
>> from your system; you may not copy this message or disclose its contents to
>> anyone. The integrity and security of this message cannot be guaranteed on
>> the Internet.
>>
>> --
>> 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 jooq-user+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 jooq-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Charles Henry
Sr. Software Engineer Snaps Team
che...@snaplogic.com

*SnapLogic Inc | 1825 South Grant Street, 5th Floor | San Mateo CA 94402 |
USA*

This message is confidential. It may also be privileged or otherwise
protected by work product immunity or other legal rules. If you have
received it by mistake, please let us know by e-mail reply and delete it
from your system; you may not copy this message or disclose its contents to
anyone. The integrity and security of this message cannot be guaranteed on
the Internet.

-- 
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 jooq-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to