apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: LONGs and LOBs [Was: improved error reporting for apr_dbd_mysql.c]
Date Thu, 01 Jun 2006 01:19:19 GMT
Quoting Chris Darroch <chrisd@pearsoncmg.com>:

>    You have to do the insert with an empty CLOB "placeholder", then
> retrieve the ID for the newly inserted row, perform a "SELECT ...
> FOR UPDATE" statement on that row ID, retrieve the OCILobLocator* for
> the CLOB from the output parameters, and finally perform OCILobWrite()
> on that locator.  Oh, and of course you need to wrap all this in
> a transaction in the case where the user hasn't already started one,
> so that you don't wind up with just the newly inserted row but
> no CLOB data in there if any error occurs along the way.

You should have warned us to take Dramamine ;-)

>    So, a quick summary:
> - get_entry() would need a buffer length return value to properly
>   support BLOBs
> - get_entry() could also use an argument to flag NULLs vs. errors
> - get_entry() could do better with memory allocation and charset issues
>   for LONGs/LOBs

I like Nick's idea with a little structure and enum/union inside.

However, we can have a new function instead, so that we remain  
backward compatible. Someting like apr_dbd_entry_get(). Or, if that's  
no good because people may expect intuitively that this is the same as  
apr_dbd_get_entry(), then maybe apr_dbd_binary_get() or something like  

> - p[v]query() supports %L now for use with LONGs and LOBs
> - p[v]query() could implement a lot of logic for "better" LOB support,
>   in which case they'll use %C[:colname] and %B[:colname] options
> - p[v]query() will also need a buffer length argument to support BLOBs fully
> - p[v]select() could support %L, %C, and %B too, but I'm unsure if
>   there's real utility in that

Why don't we use the above tricks for p[v]query/p[v]select.

First, we implement new function names to be backward compatible  
(something like p[v]bquery/bselect - "b" for binary). Some people may  
prefer to continue using the string based stuff (because it's simple)  
- no need to ditch it completely.

Second, instead of paying attention to various letters like %B, %L, %s  
and so on, which come from when the statement was prepared, we ignore  
them in p[v]bquery/bselect, but we pass apr_dbd_entry_t ** instead of  
const char ** into the function. Then we have both the type/length  
figured out explicitly and can pass binary data in safely, without the  
need to do dubious strlen()'s.


View raw message