Quoting Chris Darroch <[EMAIL PROTECTED]>:
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
that.
- 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.
--
Bojan
