apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Dubov <oa...@yahoo.com>
Subject Re: Binary data in apr dbd - where should buckets come from
Date Fri, 30 Jun 2006 08:37:45 GMT
Well, you are continuing to be non-productive.
Please, think about the problem in a following way:
You merely stated that you want to use different path
for binary api. Unfortunately, this does not help a
bit.
--------
apr_dbd_prepare()
apr_dbd_bp[v]query/select() --> takes various pointer
args
apr_dbd_get_row()
apr_dbd_get_bentry() --> returns void *
--------
The problem is, how exactly prototypes and data
structures should look like? I'm currently using an
approach that's far from perfect, but its the only way
I can use apr for my app. Description follows.

My results_t structure:
struct apr_dbd_results_t {
    int random;
    unsigned long nfields;
    MYSQL_RES *res;
    MYSQL_STMT *statement;
    MYSQL_BIND *bind;
    char *data;
    unsigned long *offset;
    unsigned long *length;
    apr_pool_t *pool;
    apr_bucket_alloc_t *bucket_alloc;
};
1: "random == 0" means that result set is not fetched
fully from the server. User must notify the api that
he's finished with particular query. I'm calling
*get_row with rownum == -1 to achieve this.

2: "res" is never used with prepared statements; its
possible to dig all the needed data from statement.
Otherwise, there's a destruction order problem between
result metadata and statement proper (with mysql, that
is).

3: "pool", "bind", "data", "offset" and "length" are
set in *select. pool argument to *get_row is never
used. "data" contains enough space for simple types
and some short space for blobs/strings.

4: *get_entry will create "bucket_alloc" first time
the bucket is needed (e.g. blob field is passed).

5: *get_entry always allocates new storage on each
invocation and copies the value from "data +
offset[n]". This means that returned pointers remain
valid across following *get_row calls. Blobs are
packed into new pool_bucket. If there's a truncation,
missing data is incrementally fetched into return
buffer at this stage.

I don't think this approach is particularly beautiful,
but it's the best I could came with. I still have some
weird problem with bucketed value not reaching
database if transaction occured just before the pool
was destroyed. May be it some bug in my software.

By the way, I do have a sound proof for stupidy of
things I call stupid. But we'll get nowhere if instead
of simply expressing an opinion, a proof would have to
be written.

With respect to api paths: it will be a very confusing
and bug prone approach to maintain such an
abomination. If I run *select in one module and
*get_entry in another, how should I figure out if it's
binary or text api? Especially if I'm not the sole
developer? To conclude: I firmly believe that for
apr_dbd to be of any use in heavy-weight applications
(and not a toyish interface), it must have clean,
unified and binary-supporting interface and not some
"this is only strings api" flimsy. Nobody expects
compatibility to be preserved across major version
change anyway.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message