Hi Lukas, LOB's would be the welcomed feature for me as well :) As to a typical use case, you said most of the time one would have to keep the content in memory anyway, but LOBs are used very often to store files uploaded by users, so you chain http input/output stream do LOBs. Sometimes you do process the data, but tools like FreeMarker also work on streams.
I know you are doing everything you can though. JOOQ is awesome, kicks ass, rulezzz and what-else, even with LOBs support without streams :) Regards, Witold Szczerba On 3 July 2013 09:12, Lukas Eder <[email protected]> wrote: > Hi Venkat, > > BLOBs and CLOBs were neglected for a while, I'm afraid. The relevant feature > request is this one: > https://github.com/jOOQ/jOOQ/issues/231 > > Currently, I have no plans of supporting JDBC LOBs more explicitly than via > String / byte[], which seems fine in most cases, i.e. with few LOBs < 100MB. > Most of the time when operating on LOBs, you will have to keep LOB content > in memory anyway, for processing with Java. I found it to be rather rare > that InputStreams and OutputStreams were chained in a way that content was > never really completely loaded. > > So, the current model works fine with small LOBs, which can easily be loaded > into Java memory. This goes along well with jOOQ's general strategy of > loading everything into memory. To a jOOQ user, 95% of your queries are > querying for Result objects that do not need to be lazy-iterated upon, such > as JDBC ResultSets force you to do. The other 5% are currently covered by > org.jooq.Cursor. > > So if true LOB support should be introduced, it would have to be lazy as > well, just as JDBCs LOB support, or just as jOOQ's Cursor. There are two > options: > > - Expose JDBC Blob and Clob types as returned by JDBC drivers > - Wrap those types in "more friendly" jOOQ types, hiding the checked > SQLException et al. > > From a functionality point of view, any solution would pretty much align > with what JDBC offers, allowing to access InputStream, OutputStream objects. > One area where jOOQ could help would be the uniform API to create LOBs. As > far as I know, with ojdbc, you still have to run 10 lines of code to create > a proprietary temporary LOB, I think? > > jOOQ's current mapping of LOBs to String / byte[] would still remain the > default. There would have to be some sort of code generator configuration, > which would allow for specifying the columns / procedure parameters based on > regexes, which should really be dealt with as LOBs. > > What do others think? > Cheers > Lukas > > > > 2013/7/3 Venkat Sadasivam <[email protected]> >> >> Lukas - I know current jOOQ doesn't support. Is it on the roadmap if in >> which release? Do you have anything in your mind on how you are planning to >> implement? >> >> -- >> 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/groups/opt_out. >> >> > > > -- > 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/groups/opt_out. > > -- 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/groups/opt_out.
