2013/7/3 Venkat Sadasivam <[email protected]> > Lukas: > > I agree that 95% cases we want to load the complete content into memory > which is the case in our application too. Only one table we need streaming > feature where we load large data. > > I could use JDBC for this but I want to know how to ignore BLOB column > generation in a specific table. >
This is currently not possible but it would be a good idea to extend the code generator's includes / excludes patterns to also match columns. In particular, the use-case of not automatically (i.e. "accidentally") fetching BLOB values is convincing. I have registered #2603 for this: https://github.com/jOOQ/jOOQ/issues/2603 Regards, > Venkat > > On Wednesday, 3 July 2013 09:03:41 UTC-4, Lukas Eder wrote: >> >> >> 2013/7/3 Witold Szczerba <[email protected]> >> >> 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. >>> >> >> So you're sure that your HTTP upload through multipart/form-data forms >> via Servlets is really streamed all the way through from the browser into >> the database, without any extensive buffering? I've always found it simpler >> to keep a byte[] around somewhere, as long as no one would upload some DVD >> image :-) Streaming error handling is just a major pain... >> >> >>> I know you are doing everything you can though. JOOQ is awesome, kicks >>> ass, rulezzz and what-else, even with LOBs support without streams :) >>> >> >> I should remember citing that verbatim somewhere ;-) >> >> Cheers >> Lukas >> >> >>> >>> 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<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 jooq-user+...@**googlegroups.com. >>> >>> >> For more options, visit >>> >> https://groups.google.com/**groups/opt_out<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 jooq-user+...@**googlegroups.com. >>> >>> > For more options, visit >>> > https://groups.google.com/**groups/opt_out<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 jooq-user+...@**googlegroups.com. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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.
