apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: LONGs and LOBs [Was: improved error reporting for apr_dbd_mysql.c]
Date Wed, 31 May 2006 18:03:57 GMT
On Wednesday 31 May 2006 18:00, Chris Darroch wrote:
> Nick Kew wrote:
> > The Oracle driver uses uppercase; %C for CLOB and %B for BLOB,
> > %L for LOB (hey, I can't even remember which of these are working
> > and which are placeholders!).  Is there any reason not to follow that
> > convention for other drivers implementing LOBs?
>
>    The Oracle driver is in an interim state at the moment with respect
> to CLOBs and BLOBs.  I use it in production with CLOBs, but it's not
> as efficient as it could be.  I will get back to it someday!

Aha, right.  I thought it had to be CLOBs we have working properly,
but just wasn't sure:-)

>    While we're on the subject, I believe there's also no easy way to
> distinguish between an error return from apr_dbd_get_entry() and
> the return of a valid NULL column value.  If we're changing the
> get_entry() function at some point in the future, could we add
> something like an int *null_flag argument that's set to 0 or 1?

I tried changing apr_dbd_get_entry once, but didn't follow through
on it.  If we're going to support LOBs (and that seems to be a
popular direction to be going), then I'd suggest returning the
data as a bucket brigade - with the option to call get_entry
multiple times if the backend supports streamed LOBs.

something like

typedef struct {
   enum { various types, error, null } type;
   union { string, integer, real, bucket brigade } data;
} apr_dbd_entry_t;


>    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
>
> - 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

Indeed.  The issue now is the API.  get_entry wants improving, but
query/select can work as-is with the above format params, and
underlying datatypes the driver understands.

Unless someone has strong views to the contrary?

-- 
Nick Kew

Mime
View raw message