Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
From: Nick Kew <nick@webthing.com>
Organization: WebThing Ltd
To: dev@apr.apache.org
Subject: Re: [PATCH]: support for types and fixes of apr_dbd_mysql.c
Date: Thu, 2 Mar 2006 11:55:50 +0000
User-Agent: KMail/1.8.3
References: <20060228015309.22229.qmail@web36702.mail.mud.yahoo.com>
In-Reply-To: <20060228015309.22229.qmail@web36702.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200603021155.53736.nick@webthing.com>

On Tuesday 28 February 2006 01:53, Alex Dubov wrote:
> I'm developing an application that requires exchange
> of binary and numeric information between MySQL and
> apr app. To reduce overhead, I introduced the
> following changes (more in the comments):
> 1. Data types are obeyed both for arguments and
> results of prepared queries
> 2. printf-style type formatters in prepared query
> strings
> 3. dbd_mysql_get_entry still returns pointer to char*,
> so programmer must have advance knowledge of data
> types involved.
>
> The patch was tested with mysql 5.0.18 and
> apr-util-1.2.2. It's made against a recent
> webthing.com version.

Thanks for the patch - looks great at first glance.  Bug me if
nothing happens!

> Compatible behavior:
> To achieve a pre-patch behavior, one can use '%c' type
> specifier for all arguments and sql's CAST(x AS CHAR)
> for all result columns.
>
> Non-prepared queries work as before.
>
> Rationale:
> I was thinking whether it will be better to return a
> complex data types instead of char* from
> dbd_*_get_entry. It seems that in vast majority of
> cases all the data types are known in compile time, so
> some clutter can be saved by keeping things simpler
> (except for blobs, whom I've wrapped into a trivial
> struct).

Agreed.  I've tinkered with that before.  What I'd like to see in a
future apr_dbd version is a new API call something like (to be finalised)

typedef struct {
  enum {
    DBD_STRING,apr_dbd_row_t *row, int col
    DBD_INT,
    DBD_REAL,
    DBD_BLOB, 
    ... /* extensible - how many types work across backends? */
  } type;
  union {
    /* the various types, or pointers/descriptors here. */
  } data;
} apr_dbd_entry_t;

apr_status_t apr_dbd_get_entry_typed(const apr_dbd_driver_t *driver,
	apr_dbd_row_t *row, int col, apr_dbd_entry_t* ret);

Or maybe just use a bucket for the typed data.

>
> P.S. By the way, was there any progress with inclusion
> of apr_dbd_mysql into apr distribution? May be mysql
> folks can give a permission for apr to include
> apr_dbd_mysql.

The mysql free software exception _looks_ fine for us.  But it's still
not clear how this might affect our users.  Some within the ASF are
not happy with that.

However, you've clearly put some considerable work into this, and
you're evidently more in touch with current MySQL than I am.  Would
it help if I give you commit access to the SVN at apache.webthing.com?
You'll see in the current version there's a call for maintainers!
Just let me know your PGP key so I can encrypt a username/password.

(it's http, not https, but is protected by digest authentication).

-- 
Nick Kew