On Tue, 20 Jul 2010 14:20:30 -0700, Tim Bunce <tim.bu...@pobox.com>
wrote:
> On Tue, Jul 20, 2010 at 09:46:42PM +0100, Martin J. Evans wrote:
> > [...]
> >
> > As a result of the above, I don't see any way of supporting the existing
> > blob_read in DBI and as it is undocumented anyway and no DBDs seem to
> > use it
>
> Feel free to mark it deprecated in the DBI docs..
>
> > I've put a test implementation together as:
> >
> > odbc_lob_read(sth, colno, buf, length, \%attrs)
> >
> > where \%attrs can contain TYPE => SQL_type.
>
> > I appreciate this RFC is quite long and I'm guessing few people will get
> > to the end. Increasingly, I'm working with several DBDs and the
> > differences between them (beyond SQL differences) is proving VERY
> > frustrating. It would be nice to try and sort out lob reading and whilst
> > I'm on a roll, SQLMoreResults/more_results, last_insert_id, lob_write,
> > binding with a specific type etc but I guess since some of these have
> > been covered before and we didn't get too far in the past that perhaps
> > there is not a lot of interest in it. I'd like to fit DBD::ODBC with
> > DBI's blob_read but I don't think it works for DBD::ODBC as it stands
> > and I note other DBDs have provided their own lob reading methods
> > substantially different so I'm guessing they found that too.
>
> I encourage driver authors to implement a 'natural' private API first
> before working together to agree on a common API for the DBI.
> (The blob_read API is an example of what happens when the DBI specifies
> things before drivers support them.)
Implementing BLOB support for Unify was extremely easy. I waited a very
long time before I started investigating what I would need to do, but
with the way Unify interfaces to its databases, I can say the
implementation took less than an hour. Unify was good in at least one
thing then :)
My blob_read function isn't even used at all
--8<---
int dbd_st_blob_read (SV *sth, imp_sth_t *imp_sth, int field,
long offset, long len, SV *destrv, long destoffset)
{
dTHX;
NYI ("st_blob_read");
return (0);
} /* dbd_st_blob_read */
-->8---
The FETCH in my code has more debug code than actual code:
--8<---
case SQLBINARY: {
auto char *s;
st_dbg (4, imp_sth, "BINARY %2d: ", ftp);
EXEC SQL
GET DESCRIPTOR :o_sql_nm
VALUE :fix
:fdX = DATA;
st_dbg (6, imp_sth, "\r\n After get, sqlcode = %d\n",
SQLCODE);
unless (sqlError (sth))
return (NULL);
i = fdX.curlen;
s = fdX.dataptr;
unless (i && s) {
s = "";
i = 0;
}
sv_setpvn (sv, s, i);
st_dbg (4, imp_sth, "(%d) %8X ...", i, SvPVX (sv));
break;
}
-->8---
and the STORE is even smaller
--8<---
case SQLBINARY: {
auto char *s;
st_dbg (4, imp_sth, "BINARY: ");
s = SvPV (value, l);
st_dbg (4, imp_sth, "(%d) %8X ...", l, s);
fdX.curlen = l;
fdX.dataptr = s;
EXEC SQL
SET SQL DESCRIPTOR :i_sql_nm
VALUE :fix
DATA = :fdX,
INDICATOR = 0;
st_dbg (4, imp_sth, " After set, sqlcode = %d\n",
SQLCODE);
unless (sqlError (sth))
return (0);
break;
}
-->8---
> > With Perl 6 perhaps on the horizon and Tim's current interest in JDBC I
> > think we are well advised to sort some of this out in Perl 5 first. It
> > makes little difference to me right now as I'll implement what I need
> > now and move on but I'm prepared to work to a DBI interface for the
> > common goal. Some of this is not going to go away - you only have to
> > watch perl monks to see the frustration with last_insert_id, lob
> > reading, binding columns with types etc across DBDs to know this is
> > proving troublesome for the average user.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
