Hi Rick,

2016-12-01 16:34 GMT+01:00 <rick.latr...@gmail.com>:

> Thanks for your support!
>
> Yes, at least it would work as expected when implementing the SPI on my
> own.
>
> But as you mentioned SPI, I second-guessed, if it makes sense at all to
> implement a JSON de/serializer in jOOQ.
> Finally you would find yourself building a jOOCKsen JSON library!?
>

You're right, that certainly shouldn't be the goal here. When I said
"custom serialisation", I didn't mean only JSON. jOOQ allows for
serialising to different formats out of the box. The only thing that's a
bit weird is the call to toString(), right now. So a new SPI (if it's
implemented, that's not decided yet), would work for all serialisation
formats.


> In my use-case using jOOQ to serialize and deserialize was quite too hasty.
>

Apart from the missing custom data type serialisation support, was there
anything else you found missing?

Maybe a library which excels on the matter of JSON de-serialization is the
> right tool.
>

Maybe. But that might mean a lot of extra work in the "default" use-case,
which is to store some data as JSON (or CSV, etc.) and then load it again
using the Loader API.

See, there are always "expert" tools for specific domains like
serialisation. But if you ever worked with SQL Developer (or a similar SQL
client), didn't you appreciate the fact that there was some out-of-the-box
CSV export from time to time? Often, that's good enough, especially if the
serialised format is not that important to you (i.e. if it's perfectly fine
if jOOQ fully controls it).

Hope this clarifies the motivation behind the existing API.
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 jooq-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to