apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: current dbd initiatives
Date Thu, 08 Jun 2006 07:04:30 GMT
Quoting Chris Darroch <chrisd@pearsoncmg.com>:

> 3) Error reporting via a standard set of APR_DBD_* error codes

Switching to APR_DBD_* error codes will *probably* break binary  
compatibility requirements for 1.x (i.e. int will become apr_status_t,  
which is probably the same thing, but I'm not sure if we're allowed to  
assume that). So, this would most likely be a 2.0 thing. Some long  
term APR folks may have more input on this...

>    Overall, this seems like a *large* effort to me.  Forewarned is
> forearmed, I guess.

Yes, this is a can of worms of gigantic proportions. We'd need to  
define a set of error codes that map into *all* underlying error  
conditions and then return that consistently. Although it's The Right  
Thing To Do (TM) and we *should* do it, I'm personally not pressed to  
go that way in a hurry - I can live with the current 0/not-zero  
situation for a while (read: too lazy to do all that work right now ;-).

> 4) I've been wondering if we should deprecate and then remove the
> apr_dbd_escape() function.
>    Because we encourage the use of placeholders, and because we
> introduce a new special character (%) which we really ought to be
> escaping as well as the usual ones

Not clear on the escaping of % here. What would be a typical use for  
escaping of prepared statements?

> 5) Renaming functions like apr_dbd_get_entry() to apr_dbd_entry_get().
> Is this the kind of thing that can be done with a minor version number
> change, i.e., in 1.3?

I think Garrett already answered this one - only possible when jumping  
major versions. So, this is something for 2.0.


View raw message