> > Apart from the missing custom data type serialisation support, was there > anything else you found missing? >
So far I didn't find any obvious functionality 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. > Yes, that was our short-term use-case. We exported data from one system, transferred it via HTTP/JSON to a remote system in order to import the data plain as it is. As we are using custom converters for data types like date-time, we ran into the mentioned issue. 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? > Yes, I'm using import/export in those tools (like SQuirrel) from time-to-time. But in code it is sometimes easier to transfer data. > 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). > Yes, that's right. -- 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.
