APR-Util DBD: Binary arguments/return values and unified parsing, 2nd approach

[Bojan Smojver <bo...@rexursive.com>]

This is a rework of the previous patches I sent to the list, but with a
new twist:

- no new structures are introduced to APU

Instead, multiple arguments are passed for BLOB/CLOB type values and
bucket brigade is returned (as in previous patches). MySQL and Oracle
drivers take advantage of brigade being returned and perform multiple
small fetches, rather than one big one.

The other important change is that the unpopular encoding in character
mode (length:table:column:payload, if you recall) of BLOB/CLOB arguments
is also gone. Instead, multiple character arguments are passed in for
such types. A lot more flexible and the caller doesn't have to stuff
already big objects into even bigger objects.

Example in pseudo code:

----------------------
apr_dbd_prepare("SELECT * FROM TEST WHERE fint = %d AND fclob = %pDc")
----------------------

And then either:

----------------------
apr_dbd_pselect("555", "clobdata", "clobsize", "test", "fclob")
----------------------                                ^       ^
                                                      |       |
                                      for Oracle <----+-------+
Or:

----------------------
apr_dbd_pbselect(&dint, "clobdata", &clobsize, "test", "fclob")
----------------------

Note that for pquery/select all arguments are still (const char *), so
everything is backward compatible. For pbquery/select they are native
APR types (in the above case dint would be int and clobsize would be
apr_size_t).

Another change is that nargs is _always_ worked out by parsing the
actual statement and legacy nargs passed to pselect/query is ignored.
New binary functions don't even have the nargs argument. You simply must
pass the correct number of values, or things will break.

As previously, this is also in the patches:

- parsing of statements is unified (i.e. not per driver)
- many types have been defined and implemented for all drivers
- binary values (including NULL) returned using apr_dbd_datum_get()

It would be great to get some feedback on this, particularly in terms of
API changes. I'm aware of the CTR policy, but I'm reluctant to commit
this rather big patch without at least some feedback.

As before, patches are in a tarball due to list size restrictions. You
will also find in there a (crude) test program and some SQL scripts to
create test tables.

-- 
Bojan

Re: APR-Util DBD: Binary arguments/return values and unified parsing, 2nd approach

[Chris Darroch <ch...@pearsoncmg.com>]

Hi --

Bojan Smojver wrote:

>> It would be great to get some feedback on this, particularly in terms of
>> API changes. I'm aware of the CTR policy, but I'm reluctant to commit
>> this rather big patch without at least some feedback.
> 
> Looks like I'll have to rely on CTR after all. So, my plan is now to
> commit this in the next few days.

   IMHO, go for it.  I know you've put in a lot of work on this and
my sense is that you've taken a lot of opinions into consideration already.

   I'm not an APR person, nor have I had much spare time to do more than
look at your patch, but it looks like a big step forward to me.  Thanks,

Chris.

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

Re: APR-Util DBD: Binary arguments/return values and unified parsing, 2nd approach

[Bojan Smojver <bo...@rexursive.com>]

On Wed, 2007-01-31 at 09:46 +1100, Bojan Smojver wrote:

> It would be great to get some feedback on this, particularly in terms of
> API changes. I'm aware of the CTR policy, but I'm reluctant to commit
> this rather big patch without at least some feedback.

Looks like I'll have to rely on CTR after all. So, my plan is now to
commit this in the next few days.

-- 
Bojan