Hi Rick, 2016-12-01 16:34 GMT+01:00 <[email protected]>:
> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
