apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: DBD: Prepared statements, BLOBs etc.
Date Wed, 06 Sep 2006 06:39:07 GMT
Bojan Smojver wrote:

> Yet another drop of the patches and the test program. Be careful with  
> these, they may actually return some data to you :-)

   Firstly, Bojan, thank you for all the work on these patches!  I read
through them last week and reviewed quickly your latest updates, and
really, I don't see much to discuss -- it's all looking very close to
what I might hope for!

   Here are my few thoughts so far.  They may not be completely cogent.

1) The one thing that stood out for me was that apr_dbd_datum_get()
   seems to take an apr_dbd_type_e parameter.  The drivers seem to
   then format the result data from the DB into the requested type.
   This means that you can ask for an APR_DBD_TYPE_NULL, for example,
   regardless of what the data is.

   Now, I may very well be missing something here, but this seems
   backwards to me.  I would have thought that you'd want to pass
   an apr_dbd_type_e *type parameter instead, and then datum_get()
   would write into that location the type of the column, and
   write into the void *data parameter the actual data, formatted
   as one would expect for the returned type.  So if the column
   contains integers, you'd get a type of APR_DBD_TYPE_INT and
   a pointer to a signed int, and so forth.

   Further, if the data in that row for that column happens to be a NULL,
   you'd get an APR_DBD_TYPE_NULL type and a NULL pointer.  That way,
   you don't need to use the proposed apr_dbd_is_null() function unless
   you're using the string-only API (i.e., the non-binary-data functions).

   Does that make any sense?  I would have thought the DB would tell
   you the type, not the caller, is what it boils down to for me.
   But, I could well be off base here.

2) Alas, for Oracle, there should probably also be the types
   APR_DBD_TYPE_CLOB and APR_DBD_TYPE_BFILE, but I can add those
   if I ever get around to implementing the Oracle version of this!  :-(

3) Defining apr_dbd_blob in apr_dbd.h means it's going to wind up
   fixed across all drivers.  Oracle would need an apr_dbd_clob too,
   or at least a common apr_dbd_lob (since the type would be specified
   elsewhere, but the data, length, table, and column need to be known
   at bind time for all LOBs in Oracle, IIRC).

   Do you see any way an apr_dbd_lob could be made private to the driver,
   and the required data fields in it queried from the driver by
   a kind of reflection method?  At one point, I proposed something
   like this, but I'll modify it a bit here:

typedef enum {
    APR_DBD_FLAGS_TABLE_NAME,
    APR_DBD_FLAGS_COLUMN_NAME
} apr_dbd_flags_e;

APU_DECLARE(apr_dbd_flags_e)
    apr_dbd_type_flags_get(const apr_dbd_driver_t *driver,
                           apr_dbd_type_e type);

   I'm thinking here that if you knew you were passing in a particular
type of bound argument after an apr_dbd_prepare(), you could query to
find out what fields you need to pack, either in the old-style string
argument or in the new-style binary structure.  Or it could be called
apr_dbd_lob_flags_get() and return an apr_dbd_lob_flags_e value:
that would clarify its usage at the expense of using the method for
any future kind of non-LOB data type.


   OK, I'm off to sleep now ... sorry if any or all of that seems
way off the mark.  Thanks again!

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

Mime
View raw message