Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of bojan@rexursive.com designates
 203.171.74.242 as permitted sender)
Message-ID: <20060907091627.keukvlkfk0ogc8gw@www.rexursive.com>
Date: Thu, 07 Sep 2006 09:16:27 +1000
From: Bojan Smojver <bojan@rexursive.com>
To: dev@apr.apache.org
Subject: Re: DBD: Prepared statements, BLOBs etc.
References: <1155589108.3289.26.camel@shrek.rexursive.com>
	<44EF3BEF.7060901@pearsoncmg.com>
	<1156537930.2596.1.camel@shrek.rexursive.com>
	<20060831092218.nh0wn8ls00cg0c88@www.rexursive.com>
	<20060904084356.7prsyaa30g4kok08@www.rexursive.com>
	<44FE6D0B.90004@pearsoncmg.com>
	<1157574895.22901.43.camel@shrek.rexursive.com>
In-Reply-To: <1157574895.22901.43.camel@shrek.rexursive.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.2)

Quoting Bojan Smojver <bojan@rexursive.com>:

> We could have others - for instance apr_dbd_file_t (for
> APR_DBD_TYPE_BFILE), which could look something like this:
>
> struct apr_dbd_file {
>     apr_file_t *file;   /**< file to read the data from */
>     apr_size_t size;    /**< size to read */
>     apr_off_t  offset;  /**< offset to read from */
>     const char *table;  /**< table name (used for Oracle) */
>     const char *column; /**< column name (used for Oracle) */
> };

Actually, please disregard this part of my reply. I'll blame it on =20
early morning, although we all know that's not true ;-)

Seriously, for something like this to be useful, databases would need =20
to know how to take an open file descriptor, offset and size and use =20
that as input to execPrepared (and similar). These functions usually =20
expect a pointer to a chunk of memory and size or nul terminated =20
string, so the above probably wouldn't be useful at all.

Which brings me to my reasoning why apr_dbd_blob_t doesn't contain a =20
brigade (one of the proposals that was floating on the list), but =20
rather a flat data pointer and size (in case you were wondering). The =20
caller is in a much better position to control memory allocation =20
issues here and leaving the "flattening" of a brigade to DBD functions =20
can bring about all kinds of unwanted memory allocation effects. In =20
the end, most databases deal with a flat chunk of memory and that's =20
what callers mostly have anyway.

--=20
Bojan