Re: RFC: [b]lob_read in DBD::ODBC and other DBD differences

On Tue, 20 Jul 2010 14:20:30 -0700, Tim Bunce <[email protected]>
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/