Login | Register
My pages Projects Community openCollabNet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Catacomb] Pool and result abstraction



Sung Kim wrote:

Probably it is good idea get pool in dbms_prepare not dbms_create. Also dbms_query needs pool instead of dbms_db.
Please see the changes I've checked into the branch...Primarily, all of the dbms_prepare/execute/etc. functions take a memory pool as an argument. The dav_repos_dbms type is now just a typedef to MYSQL. (Eventually, we can get rid of the mysql component in the dav_repos_db type...But not until we wrap the results processing.)

Most of the dbms.c functions create a child pool, perform their queries, then destroy the pool before returning. There are a couple exceptions, primarily where a pool (instead of dav_repos_resource) is passed into the function. I could make a child pool in these, but I suspect there is a reason for passing a pool not a resource struct.

Also, I'd like to recommend to use dav_buffer. It is very handy. :-)

/* set the cur_len to the given size and ensure space is available */
DAV_DECLARE(void) dav_set_bufsize(apr_pool_t *p, dav_buffer *pbuf,
                                 apr_size_t size);

/* initialize a buffer and copy the specified (null-term'd) string into it */
DAV_DECLARE(void) dav_buffer_init(apr_pool_t *p, dav_buffer *pbuf,
                                 const char *str);

/* check that the buffer can accomodate <extra_needed> more bytes */
DAV_DECLARE(void) dav_check_bufsize(apr_pool_t *p, dav_buffer *pbuf,
                                   apr_size_t extra_needed);

/* append a string to the end of the buffer, adjust length */
DAV_DECLARE(void) dav_buffer_append(apr_pool_t *p, dav_buffer *pbuf,
                                   const char *str);

The query construction phase may be able to take advantage of this, yes. Although it's not a long process of appending strings, it's easy to calculate the total length of the buffer the query construction will take, so this may be unneeded overhead.

Sorry to make this mail very long.
We need to have abstract result struct too.
That'd be next, yes.