[DB-SIG] over the API

pierre@saiph.com pierre@saiph.com
Fri, 25 May 2001 13:08:30 +0200 (CEST)


    I have the feeling, and many people seem to have the same, I lack
    some obvious functionnality when using the DB-api; I have seen
    many demands to add functionnality on this list, and a good answer
    to this: lets not increase the burden of the implementers: if its
    too high, people will become reluctant to comply to the API;

    So I think we should take the problem some other way; Ill explain
    this with the C/UNIX interface: The C developper on an UNIX
    machine can use functions from 2 distinct library sets:
     - system calls: these are C wrappers to the UNIX API: a very
     minimal set of functions, designed not to be handy, but to
     provide ALL the functionnality needed to drive the system; it
     does not pretend to be handy, it does not have to: it has to be
     solid, well documented, complete.
     - library functions: this is an other layer, written in C, well
     documented too, providing the handiness one cant find at the
     system call level.
     - system calls implementation is system dependent, libraries are
     not: when a new system is built (on a new processor, for
     instance), only system calls give a hard time (assembler
     function, direct access to registers, for instance), libraries
     are just compiled.
     Some (most?) of these library functions have been put in the C
     ANSI specification, hence can be called from a program whatever
     the system: (Unix, dos, mac).  They form a natural new API for
     developpers with portability concerns.

    So I think this is just what is needed here: a library module,
    layer between the app accessing the DB, and the actual module
    implementing the DB API;
    Examples of functionnalities to put there:
       - row objects with easy to access colums (row['col'], or
       row.col)
       - Automatic building of queries, from a {col: 'value'} dict.
    OK, I guess its a mess to agree on, some work to develop. I guess
    its a long-time project. And maybe its not one module but many,
    and maybe incompatible solutions too.
Too bad, in the meantime, Ill develop my own function set.

--=20
Pierre Imbaud <pierre@saiph.com>
12 Rue des Bosquets 91480 Quincy Sous S=E9nart France
Tel:  01 69 00 94 57 Fax 09 47